NetCDF coordinate variables provide scales for the space and time axes for the
multidimensional data arrays, and must be included for all dimensions that can
be identified as spatio-temporal axes.
Coordinate arrays are used to geolocate
data arrays on non-orthogonal grids, such as images in the original pixel/scan
line space, or complicated map projections. Required attributes are units and
_FillValue. Elements of the coordinate array need not be monotonically
ordered. The data type can be any and scaling may be implemented if required.
add_offset and scale_factor have to be adjusted according to the sensor
resolution and the product spatial coverage. If the packed values can not stand
on a short, float can be used instead (multiplying the size of these variables
by two).
time is the reference time of the SST data array. The GDS-2.1r0
specifies that this reference time should be extracted or computed to the
nearest second and then coded as continuous UTC time coordinates in
seconds from 00:00:00 UTC January 1, 1981 (which is the definition of the
GHRSST origin time, chosen to approximate the start of useful AVHRR SST data
record). Note that the use of UDUNITS in GHRSST implies that that calendar to
be used is the default mixed Gregorian/Julian calendar.
The reference time used is dependent on the of the data and
is defined as follows:
Processing level
Reference time
L2P
start time of granule
L3U
start time of granule
L3C
centre time of the collation window
L3S
centre time of the collation window
L4
nominal time of the analysis
The coordinate variable time is intended to minimize the size of the
sst_dtime variable (e.g., see Section 7.2.2), which stores
offsets from the reference time in seconds for each SST pixel. time also
facilitates aggregation of all files of a given dataset along the time axis with
such tools as THREDDS or when building data cubes.
x (columns) and y (lines) grid dimensions are referred either as lat
and lon or as ni and nj. lon and lat must be used if data are mapped
on a regular grid (some geostationary products). ni and nj are used if data
are mapped on a non-regular grid (curvilinear coordinates) or following the
sensor scanning pattern (scan line, swath). It is preferred that ni should be
used for the across-track dimension and nj for the along-track dimension.
Coordinate vectors are used for data arrays located on orthogonal (but not
necessarily regularly spaced) grids, such as a geographic (lat-lon) map
projections. The only required attribute is units. The elements of a
coordinate vector array should be in monotonically increasing or decreasing
order. The data type can be any and scaling may be implemented if required.
A coordinates variable attribute (coordinates="lonlat";) must be
provided if the data are on a non-regular lat/lon grid (map projection or
swath data).
A grid_mapping variable attribute (grid_mapping="<projectionname>";)
must be provided if the data are mapped following a projection. Refer to the
CF convention[1] for standard projection names.
Note on lat/lon arrays
lat and lon arrays are the only arrays stored as float in GHRSST product
files and therefore can represent a major fraction of the overall data
volume. As an optimization factor, producers are encouraged to make use of the
least_significant_digit argument when creating these NetCDF variables (refer
for instance to https://unidata.github.io/netcdf4-python/): in most current
GHRSST products, there is no need for a precision larger than 3 digits and
it can be a big volume saver.
This is the simplest case. Many Level 3 and Level 4 products as well as some
geostationary L2P products are provided on a regular lat/lon grid. On such a
projection, only two coordinate variables are requested and they can be stored
as vector arrays. Longitudes should range from -180 to +180, corresponding to
180 degrees West to 180 degrees East. Latitudes should range from -90 to +90,
corresponding to 90 degrees South to 90 degrees North. There should be no
_FillValue for latitude and longitude and all SST pixels should have a valid
latitude and longitude value.
It is recommended that for Level 3 and Level 4 data products the time
dimension be specified as unlimited. Note that the time dimension for L2P
data files is strictly defined as time=1 (unlimited dimension not allowed).
This strict definition is because L2P data are swath based and the geospatial
information may change across consecutive time slabs. Although in GHRSST L3 and
L4 granules there is only one time dimension and variable time has only one
value (seconds since 1981), setting an unlimited dimension for time dimension
will allow netCDF tools and utilities to easily concatenate (and average for
example) a series of time consecutive GHRSST granules. The following CDL is
provided as an example:
For these cases, dimension and coordinate variables shall be used for a regular
lat/lon grid as shown in Table 6.1. No specific variable
attributes are required for other variables (like sea_surface_temperature as
shown in the example given in Table 6.1).
Table 6.1 Example CDL for geographic regular latitude/longitude grids#
geographic regular latitude/longitude grids
netcdf regular_grid {
dimensions:
time = UNLIMITED ; // (1 currently)
lat = 1800 ;
lon = 3600 ;
variables:
int64 time(time) ;
time:axis = "T" ;
time:long_name = "reference time of sst file" ;
time:standard_name = "time" ;
time:coverage_content_type = "coordinate" ;
time:units = "seconds since 1981-01-01" ;
time:calendar = "proleptic_gregorian" ;
float lat(lat) ;
lat:axis = "Y" ;
lat:long_name = "latitude" ;
lat:standard_name = "latitude" ;
lat:coverage_content_type = "coordinate" ;
lat:units = "degrees_north" ;
lat:comment = "geographical coordinates, WGS84 projection" ;
lat:valid_range = -90., 90. ;
float lon(lon) ;
lon:axis = "X" ;
lon:long_name = "longitude" ;
lon:standard_name = "longitude" ;
lon:coverage_content_type = "coordinate" ;
lon:units = "degrees_east" ;
lon:comment = "geographical coordinates, WGS84 projection" ;
lon:valid_range = -180., 180. ;
short sst_dtime(time, lat, lon) ;
sst_dtime:_FillValue = -32768s ;
sst_dtime:long_name = "time difference from reference time" ;
sst_dtime:coverage_content_type = "coordinate" ;
sst_dtime:units = "s" ;
sst_dtime:comment = "time plus sst_dtime gives seconds after 00:00:00 UTC January 1, 1981" ;
sst_dtime:valid_range = -32767s, 32767s ;
sst_dtime:add_offset = 0. ;
sst_dtime:scale_factor = 1. ;
short sea_surface_temperature(time, lat, lon) ;
sea_surface_temperature:_FillValue = -32768s ;
sea_surface_temperature:long_name = "Skin temperature of the sea surface" ;
sea_surface_temperature:standard_name = "sea_surface_skin_temperature" ;
sea_surface_temperature:coverage_content_type = "physicalMeasurement" ;
sea_surface_temperature:units = "K" ;
sea_surface_temperature:comment = "These SST values are representative of the top 10 micrometers of the sea surface and were generated on a regular grid" ;
sea_surface_temperature:valid_range = -200s, 5000s ;
sea_surface_temperature:add_offset = 273.15 ;
sea_surface_temperature:scale_factor = 0.01 ;
}
For gridded data using a specific projection (such as stereographic projection),
lat/lon have to be stored in 2-D arrays. When data are gridded following the
sensor pattern, no projection can be associated and lat/lon data have to be
stored in 2-D arrays. Dimensions cannot be referred to as lat/lon anymore since
the x and y axes of the grid are not related to the latitude or
longitude axis. Each variable must explicitly provide a reference to its
coordinate variables (coordinates variable attribute) and to the related
projection (grid_mapping variable attribute) described in a specific variable
(for example, Lambert_Azimuthal_Grid", in the example given in
Table 6.2, refer to CF convention
[1] for standard projection names).
In these cases, dimension and coordinate variables shall be used for a
non-regular lat/lon grid (projection) as shown in
Table 6.2. A specific projection coordinate
variable shall be added (for example, Lambert_Azimuthal_Grid), following the
CF-1.7 or later convention. The specific variable attributes
coordinates="lonlat" andgrid_mapping="Lambert_Azimuthal_Grid" are
required for each other variables (like sea_surface_temperature in the example
given in Table 6.2).
Note that variable attributes such as grid_mapping may be set differently
(when using a different kind of projection) or completely removed (for swath
products or regular grids if required).
Table 6.2 Example CDL for non-regular latitude/longitude grids (projection)#
6.2.3. Non-regular latitude/longitude grids (projection) – alternative without explicit latitude/longitude#
For gridded data using a fixed specific projection (such as geostationary
projection), the same lat/lon 2-D arrays are repeated from file to file. If a
fixed projection can be associated to lat/lon data, it is also permitted by CF
convention to provide a projection variable defining this projection, instead of
providing explicit latitude/longitude 2-D arrays as in the previous section.
This usually allows to save significant storage (which is interesting for
products with a high temporal repetitiveness such as geostationary products in
satellite projection) while being less user friendly since users will have to
calculate their own latitude/longitude 2-D arrays from the projection parameters
(this is done automatically in some CF compliant tools). The projection variable
must be named with the projection name used in the product (like geostationary
below). It is dimensionless and of type int. The naming and content of this
projection variable is described in CF conventions[1].
The x (abscissa) and y (ordinate) rectangular coordinates must be
provided in ni and nj variables, identified by the standard_nameattribute
values projection_x_coordinate and projection_y_coordinate respectively.
In the case of this geostationary projection, the projection coordinates in this
projection are directly related to the scanning angle of the satellite
instrument, and their units are radians.
Each variable must explicitly provide a reference to its coordinate variables
(coordinates variable attribute) and to the related projection (grid_mapping
variable attribute) described in a specific variable (e.g. geostationary in the
example given in Table 6.3; refer
to CF convention[1] for standard projection names).
In these cases, dimension and coordinate variables shall be used for a
non-regular lat/lon grid (projection) as shown in
Table 6.3. A specific projection
coordinate variable shall be added (for example, geostationary), following the
CF-1.7 or later convention. The specific variable attributes
coordinates="njni" and grid_mapping="geostationary" are required for
each other variables (like sea_surface_temperature in the example given in
Table 6.3).
Table 6.3 Example CDL for Non-regular latitude/longitude grids (projections) alternative form with no explicit latitudes/longitudes#
non-regular latitude/longitude grids (projections) with no explicit latitude/longitude
In this case where data are gridded following the sensor pattern, no projection
can be associated and lat/lon data have to be stored in 2-D arrays, as it is
the case for along-swath data for low earth orbiting sensors or geostationary
orbiting sensor data in their native projection. Therefore it only applies
to L2P processing level products.
Dimensions cannot be referred to as lat/lon anymore since x and y axes of the
grid are no more related to the latitude or longitude axis. Instead, dimensions
ni and njshould be used to describe the swath. As a best practice, the ni
dimension should refer to the cross-track direction and the nj dimension
should refer to the along-track direction of a polar orbiting (or similar)
satellite sensor swath. For geostationary sensors ni also refers to the
cross-disk direction and nj the along-disk direction. Each variable must
explicitly provide a reference to its coordinate variables (using the
coordinates variable attribute) and pixel times must be encoded using the
combination of timeand sst_dtime coordinate variables.
Dimension and coordinate variables shall be used for a non-regular lat/lon grid
(swath product file) as shown in Table 6.4. The specific
variable attribute coordinates="lonlat" is required for each of the
variables (like sea_surface_temperature below).
Table 6.4 Example CDL for non-regular latitude/longitude grids (swath)#
The Recommended GHRSST Data Specification (GDS) Version 2.1r0
The Recommended GHRSST Data Specification (GDS) Version 2.1r0#
A new generation of integrated Sea Surface Temperature (SST) data products are
being provided by the Group for High Resolution Sea Surface Temperature
(GHRSST).
L2 products are provided by a variety of data providers in a common
format. L3 and L4 products combine, in near-real time, various SST data products
from several different satellite sensors and in situ observations and maintain
fine spatial and temporal resolution needed by SST inputs to a variety of ocean
and atmosphere applications in the operational and scientific communities. Other
GHRSST products provide diagnostic data sets and global multi-product ensemble
analysis products. Retrospective reanalysis products are provided in a non-real
time critical offline manner. All GHRSST products have a standard format,
include uncertainty estimates for each measurement, and are served to the
international user community free of charge through a variety of data transport
mechanisms and access points that are collectively referred to as the GHRSST
Regional/Global Task Sharing (R/GTS) framework.
The GHRSST Data Specification (GDS) Version 2.1r0 is a technical
specification of GHRSST products. The GHRSST services are described in a
separate Architecture Document (GSA).
The GDS technical documents are supported by a User Manual. GDS 2.1r0
represents a consensus opinion of the GHRSST international community on how to
optimally combine satellite and in situ SST data streams within the R/GTS. The
GDS also provides guidance on how data providers might implement SST processing
chains that contribute to the R/GTS.
This document first provides an overview of GHRSST followed by detailed
technical specifications of the adopted file naming specification and supporting
definitions and conventions used throughout GHRSST and the technical
specifications for all GHRSST Level 2P, Level 3, Level 4.
In addition, the GDS 2.1r0 Technical Specification provides controlled
code tables and best practices for identifying sources of SST and ancillary data
that are used within GHRSST data files.
The GDS document has been developed for data providers who wish to produce any
level of GHRSST data product and for all users wishing to fully understand
GHRSST product conventions, GHRSST data file contents, GHRSST and Climate
Forecast definitions for SST, and other useful information. For a complete
discussion and access to data products and services, see https://www.ghrsst.org,
which is a central portal for all GHRSST activities.
7.1. Overview description of the GHRSST L2P data product#
The GHRSST Level-2 Pre-processed (L2P) products are the basic building blocks
from which all other GHRSST SST data products can be derived. L2P data products
should ideally be made available within the GHRSST R/GTS framework to the user
community in real time within 3 hours after the reception of data at the
satellite.
L2P products include SST data as delivered by a data provider in their native
format (swath for polar orbiting satellite), together with a number of
ancillary fields that simplify interpretation and application of the SST data.
The main difference between input L2 SST data file and the output GHRSST L2P
data file is that additional confidence data and sensor specific error estimates
for each pixel value are included and the original SST data files are
reformatted into the L2P specification. No adjustments to the input L2 SST
measurements are allowed but instead, sensor specific error statistics are used
to provide bias error and standard deviation estimates. A user wishing to
correct L2P SST data can apply these estimates to the SST values directly.
Full orbit input data files may be split into ascending and descending files or
smaller granules and a unique L2P output may be generated for each file.
The common format of L2P products allows data users to code with the security
so that as new satellite derived SST data sets are brought on-line, very minimal
code changes are required to make full use of new L2P data. Time previously
spent on coding different i/o routines for each satellite data set can now be
spent applying the data to various applications and societal benefits instead.
The GHRSST Science Team agreed at the 6th GHRSST Science Team Meeting, Met
Office, Exeter, United Kingdom, May 14th – 20th 2005, 6 mandatory fields form
the core data content of a GHRSST L2P data file. These fields will be known as
L2P ‘core’ (L2Pcore) fields. In addition to global attributes and
geo-location and time information, GHRSST producers must provide the following
L2Pcore fields within an L2P file:
Sea Surface Temperature data (sea_surface_temperature)
Time differences of SST measurements from a reference time (sst_dtime)
SST Sensor Specific Error Statistic (SSES) measurement bias estimate
(sses_bias)
SSES measurement standard deviation estimate (sses_standard_deviation)
Flags specific to each L2P data set that help users interpret data
(l2p_flags)
A quality level for each measurement (quality_level)
In addition there are a number of auxiliary fields (L2Paux) that must be
provided before the L2P data product is admitted into the GHRSST R/GTS:
the difference between satellite SST measurements and a
defined reference climatology of SST (dt_analysis)
An estimate of surface wind speed (wind_speed)
An estimate of sea ice fraction (sea_ice_fraction)
An estimate of atmospheric aerosol (as an aerosol dynamic indicator,
aerosol_dyanamic_indicator)
When an L2P file contains all L2Pcore and L2Paux fields together, it will be
called a full-L2P file. Only full L2P data files should be registered
into the GHRSST R/G TS central catalogue. These distinctions will assist in the
data management of the GHRSST GDS-2.1r0.
Missing L2Paux fields not provided by a producer may be added by a GHRSST
distributor (DAC), if different from the producer, with prior arrangement. In
this case data required the L2Paux files will be procured, checked for quality
and interpolated or processed according to the GDS-2.1r0 specification
by the DAC.
Optional experimental fields may be used by producers to provide additional
information at their discretion. It may be necessary to use an additional
netCDF coordinate variable when including experimental fields.
GDS-2.1r0 L2P data products are configured as shown in the table
Table 7.1, which can be used to locate appropriate
information in this document.
Table 7.1 Summary description of the contents of a GHRSST L2P data product#
netCDF File Contents
Description
Coordinate variables
Information to permit locating data on non-orthogonal grids, as defined in Section 6
Data record variables
Core and auxiliary variables as defined in Section 7.2
Global Attributes
A collection of required global attributes describing general characteristics of the file, as defined in section Section 5.2
The Table 7.2 provides an overview of the GHRSST L2P
product pixel data record that should be created for each input L2 SST
measurement contained within a L2P file. In the following sections, each
variable within the L2P data file is described in detail.
Table 7.2 Summary description of GHRSST L2P data records#
The variable sea_surface_temperature contains the native unmodified L2 SST
of the input data file. L2 SST data are not adjusted in any manner and are
identical to the input data set.
The sea_surface_temperature variable shall be included in a L2P product
with the format requirements shown in table
Table 7.3.
Table 7.3 CDL example description of sea_surface_temperature variable#
The deviation in time of SST measurement from reference time stored in the
netCDF coordinate variable time (defined as the start time of granule for L2P).
Minimum resolution should be one second.
The sst_dtime variable shall be included in a L2P product with the format
requirements shown in table Table 7.5.
Table 7.5 CDL example description of sst_dtime variable#
Storage type
Name
Description
Unit
short
sst_dtime
Deviation from reference time stored in the coordinate variable, time
s (seconds)
short sst_dtime(time, nj, ni) ;
sst_dtime:_FillValue = -32768s ;
sst_dtime:long_name = "time difference from reference time" ;
sst_dtime:units = "s" ;
sst_dtime:scale_factor = 1. ;
sst_dtime:add_offset = 0. ;
sst_dtime:coverage_content_type = "coordinate" ;
sst_dtime:comment = "time plus sst_dtime gives seconds after 00:00:00 UTC January 1, 1981" ;
sst_dtime:coordinates = "lat lon" ;
Providing uncertainty estimates for each SST measurement is one of the key user
requirements for GHRSST L2P SST data products. Uncertainty estimates allow users
to select the accuracy level suitable for their application and to make optimum
use of the SST observations (e.g. in data assimilation).
The uncertainties associated with each observation in a data stream are provided
as Sensor Specific Error Statistic (SSES). The SSES are based on
understanding the errors associated with the in-flight performance of an
individual satellite instrument for the retrieval of SST from the measured
radiances. The SSES are provided as a mean bias error and its associated
standard deviation (in variable sses_standard_deviation, see
Section 7.2.4).
There are a variety of methods for determining SSES as they depend on the
specific characteristics of each satellite instrument. Consequently, the L2P
provider can define their own scheme for producing SSES that is tailored to
their specific dataset. However, the SSES scheme must conform to a set of agreed
SSES common principles.
The SSES common principles are maintained on the
GHRSST website, and
have been approved by the GHRSST Science Team. The L2P provider must provide
documentation that summarizes the theoretical basis of their SSES scheme, its
implementation, any recommendations for users, and its conformance to the agreed
SSES common principles.
The variable sses_bias is used to store SSES bias estimates and shall be
included with the L2P format requirements shown in Table 7.6. Data
producers are reminded to choose appropriate scale_factor and add_offset
attributes for their data, and to strive for scale_factor as close to 0.01 as
possible without “oversaturating” the values.
Table 7.6 CDL example description of sses_bias variable#
Sensor Specific Error Statistic (SSES) standard deviation estimates are
generated by the L2P data provider and are specific to a particular satellite
instrument, and must conform to the SSES common principles. See
Section 7.2.3 for the general description of SSES concept and
associated variables.
The variable sses_standard_deviation shall be included with the format
requirements shown in Table 7.7.
Data producers are reminded to choose appropriate scale_factors and
add_offsets for their data, and to strive for scale_factors as close to
0.01 as possible without “oversaturating” the values.
Table 7.7 CDL example description of sses_standard_deviation variable#
Storage type
Name
Description
Unit
byte
sses_standard_deviation
SSES standard deviation.
K (kelvin)
byte sses_standard_deviation(time, nj, ni) ;
sses_standard_deviation:_FillValue = -128b ;
sses_standard_deviation:long_name = "SSES standard deviation" ;
sses_standard_deviation:units = "K" ;
sses_standard_deviation:comment = "Standard deviation estimate derived using the techniques described at http://www.ghrsst.org/SSES-Description-of-schemes.html" ;
sses_standard_deviation:coverage_content_type = "qualityInformation" ;
sses_standard_deviation:coordinates = "lat lon" ;
sses_standard_deviation:add_offset = 1. ;
sses_standard_deviation:scale_factor = 0.01 ;
The difference between input SST and a GHRSST L4 SST analysis from the
previous 24 hour period. If storage as byte
does not allow the provider to offer the full precision required for this
field, storage as a short is optionally permitted though byte is preferred.
The L2P variable dt_analysis is the temperature difference between an input
L2 SST measurement and a reference SST L4 analysis data set. dt_analysis may
be used to indicate potential areas of diurnal variability or gross outliers in
the L2 input SST measurement data set by looking for large deviations from the
previous analysis SST data. Note that dt_analysis is an indicator field and
the temperature anomalies may be difficult to interpret in regions of high SST
gradients. Furthermore, interpretation requires a good understanding of the
strengths and weaknesses (e.g. space and time de-correlations) of the chosen
reference L4 analysis system.
Where SSTinput is the input satellite L2 measurement and L4
SST is a previous day analysis from a GHRSST L4 System selected by the
data provider. The GHRSST L4 analysis chosen for a given L2P data set variable
should be consistent for all L2P products as far as practically possible. If a
previous analysis SSTfnd data file is not available for use in
(7.1), then a mean reference SST or climatology should be
used in its place as defined in Table 7.8.
Table 7.8 Reference SST data sets for use in dt_analysis computation#
Name
Description
Reference
Use code from L4 analysis
The mean SSTfnd computed for a n-1 day period. This product is computed from data provider SSTfnd data products in real time each day
The dt_analysis value shall be inserted into the dt_analysis field of
the L2P product for the pixel in question as described
Table 7.9.
Table 7.9 CDL example description of dt_analysis variable#
Storage type
Name
Description
Unit
byte or short
dt_analysis
Deviation from previous day (T-1) L4 SSTfnd analysis as defined in the Table 7.8. If no analysis is available, the reference mean SST climatology should be used
K (kelvin)
byte dt_analysis(time, nj, ni) ;
dt_analysis:_FillValue = -128b ;
dt_analysis:long_name = "deviation from SST analysis or reference climatology" ;
dt_analysis:units = "K" ;
dt_analysis:reference = "OSTIA" ;
dt_analysis:comment = "The difference between this SST and the previous day\'s SST analysis" ;
dt_analysis:coverage_content_type = "auxiliaryInformation" ;
dt_analysis:coordinates = "lat lon" ;
dt_analysis:add_offset = 0. ;
dt_analysis:scale_factor = 0.1 ;
Note
The reference variable attribute should be used to specify the analysis or
climatology used to compute dt_analysis as shown in the example above
following the guidelines in Table 7.8.
The L2P variable wind_speed contains a best estimate of the 10m surface
wind speed, ideally at the time of SST data acquisition (although this is
rarely possible). Wind speed measurements are required within the GDS as an
indicator of the turbulent state of the air sea interface to interpret the
relationship between satellite and subsurface SST data and assess the severity
of any skin SST temperature deviation, thermal stratification and for use in
diurnal variability adjustment schemes. At low wind speeds, especially in clear
sky conditions, stronger diurnal variability is expected leading to higher
surface layer temperature gradients and the potential for significant
de-coupling of the skin/sub-skin SST from the SST at depth.
Ideally a near contemporaneous wind speed measurement from satellite sensors
should be used but this is impossible for all sensors due to the limited number
of satellite wind speed sensors available. As a surrogate for a measured wind
speed value, analysis product estimates (e.g., from numerical weather prediction
models) may be used as an indication of the surface wind speed. The GDS
specifies the following rules:
Simultaneous microwave 10m wind speed measurements obtained from the same
instrument providing the SST measurement shall be used when available to set the
L2P confidence data variable wind_speed.
In the absence of a simultaneous surface wind speed measurement, an analysis
product estimated 10m surface wind speed shall be used to set the L2P variable
wind_speed.
The difference in time expressed in hours between the time of SST measurement
and the time of wind speed data should be entered into the L2P confidence data
variable wind_speed_dtime_from_sst as described in
Section 7.2.7. In the case of an analysis field,
this should be the central (mean) time of an integrated value.
If all of the wind speeds have a single time value, as in the case of an
analysis or model that gives the wind speeds at an instant in time, then the
wind_speed_dtime_from_sst variable is not needed and instead a variable level
attribute named time_offset is used. The attribute time_offset should
store the difference in hours between the wind_speed and the reference time,
stored in the variable time.
If a single source of data is used in the L2P variable wind_speed
(recommended), the L2P variable source_of_wind_speed is not required and a
source variable attribute of wind_speed is sufficient. In that case, it
shall be a single source text string defined by the data provider using the text
string naming best practice given in Section 4.9.
If multiple sources of data are used, source information should be indicated in
the L2P variable source_of_wind_speed as defined by the data provider and as
described in detail in Section 7.2.8, and the
source variable attribute of wind_speed shall have the value
source_of_wind_speed. In addition, the units of all sources used in the file
shall be identical.
The GDS L2P variable wind_speed shall be included in L2P products
with the format requirements shown in the Table 7.10.
Table 7.10 CDL example description of wind_speed variable#
Storage type
Name
Description
Unit
byte
wind_speed
Surface wind speed at 10m height. Resolution should be no less than 1 m s-1
A single source of wind data is shown in this example which is reported as
wind_speed:source="ECMWF_Anaylsis_V2" the code has been defined by the data
provider using the ancillary data naming rules given in Section 4.9.
Since all of the wind speeds have the same time, the attribute time_offset is
used instead of the variable wind_speed_dtime_from_sst.
The variable wind_speed_dtime_from_sst reports the time difference between
wind speed data and SST measurement in hours. The variable
wind_speed_dtime_from_sst shall be included with the format requirements
shown in Table 7.11. In the
case of an analysis field, the central (mean) time of an integrated value should
be used. If all values are the same, this variable is not required.
Instead, use the variable level attribute named time_offset with the
variable wind_speed.
Table 7.11 CDL example description of wind_speed_dtime_from_sst variable#
Storage type
Name
Description
Unit
byte
wind_speed_dtime_from_sst
This variable reports the time difference of wind speed measurement from SST measurement in hours.
h (hour)
byte wind_speed_dtime_from_sst(time, nj, ni) ;
wind_speed_dtime_from_sst:_FillValue = -128b ;
wind_speed_dtime_from_sst:long_name = "time difference, in hours\', of wind speed measurement from sst measurement" ;
wind_speed_dtime_from_sst:units = "h" ;
wind_speed_dtime_from_sst:scale_factor = 0.1 ;
wind_speed_dtime_from_sst:add_offset = 0. ;
wind_speed_dtime_from_sst:coverage_content_type = "auxiliaryInformation" ;
wind_speed_dtime_from_sst:comment = "the hours between the wind speed measurement and the SST observation" ;
wind_speed_dtime_from_sst:coordinates = "lat lon" ;
The source of data used to set the L2P ancillary data variable wind_speed
shall be indicated in the L2P variable source_of_wind_speed when more than
one source of wind speed data is used in the L2P product.
When only one source is used, this variable is not needed and the appropriate
text string indicating the source is placed in the source attribute of the
wind_speed variable. If the values in that single source all have the same
time, then a variable attribute time_offset set as the difference time in
hours is considered sufficient and the variable wind_speed_dtime_from_sst
is not required.
For multiple sources, the GDS-2.1r0 requires the following:
The variable in question should contain an attribute called flag_meanings
and another one called flag_values. The flag_values attribute shall
contain a comma-separated list of the numeric codes for the sources of data
used whose order matches the comma-separated text strings in the
flag_meanings attribute.
These text strings and numeric codes do not need to be unique across different
data sets or even ancillary variables, but must be consistent within a given
variable and clearly specified within each netCDF variable and its attributes.
A best practice for naming the text strings in provided in Section 4.9.
instead of using a _FillValue attribute and value for missing data, it is
recommended to set missing pixel values to 0 and add the corresponding
no_data meaning in flag_meanings attribute.
The variable source_of_wind_speed shall conform to the format requirements
shown in the Table 7.12.
Table 7.12 CDL example description of source_of_wind_speed variable#
Storage type
Name
Description
Unit
byte
source_of_wind_speed
Sources of wind_speed values.
code
byte source_of_wind_speed(time, nj, ni) ;
source_of_wind_speed:long_name = "sources of wind speed" ;
source_of_wind_speed:flag_meanings = "no_data WSP-ESA-ASCAT-V2 WSP-NCEP-Analysis-V3 WSP-ECMWF-Forecast-V6" ;
source_of_wind_speed:flag_values = 0b, 1b, 2b, 3b ;
source_of_wind_speed:coverage_content_type = "auxiliaryInformation" ;
source_of_wind_speed:comment = "This variable provides a pixel by pixel description of where the wind speeds were derived from." ;
source_of_wind_speed:coordinates = "lat lon" ;
In this example, flag_meanings and flag_values contain strings and
numeric codes provided by the data provider according to the best practices
specified in Table 7.12.
Some SST data are contaminated in part or wholly by sea ice and the L2P variable
sea_ice_fraction is used to quantify the fraction of an area contaminated
with sea ice, ranging from 0 to 1. Some input SST data streams provide a
flag to indicate that the SST measurement is contaminated by sea ice
(e.g., passive microwave radiometers such as AMSR-E).
If an input data set pixel fractional sea ice estimate exists, this should be
used to in the L2P variable sea_ice_fraction as described in the
table Table 7.13.
Best practice suggests that one should approach the issue in the following
way. If an input data set pixel sea ice flag does not exist, and the pixel is
located in or close to a region that may be ice contaminated, a reference sea
ice data set should be used to determine the value of the L2P variable
sea_ice_fraction.
If an input data set pixel sea ice flag exists (i.e. indicating sea ice but
not the fractional amount of coverage), this should be used to set the L2P
variable sea_ice_fraction to 1.
If the SST input data set includes a sea ice flag in the data stream, bit 3 of
the L2P confidence data variable l2p_flags should be set for this pixel as
described in Section 7.2.15.
The difference in time expressed in hours between the time of SST measurement
and the time of sea ice fraction measurement should be entered into the L2P
variable sea_ice_fraction_dtime_from_sst as described in
in Section 7.2.10. In the case of an
analysis field, this should be the central (mean) time of an integrated value.
If all ice observations have a single time value, as in the case of an
analysis or model that gives the sea ice values at an instant in time, then the
sea_ice_fraction_dtime_from_sst variable is not needed and instead a
variable attribute named time_offset is used. The attribute time_offset
should store the difference in hours between the sea_ice_fraction
and the reference time, stored in the variable time.
If a single source of data is used in the L2P variable sea_ice_fraction, the
L2P variable source_of_sea_ice_fraction is not required and instead the
source variable attribute value of sea_ice_fraction is sufficient. It shall
be a single source text string defined by the data provider using the text
string naming best practice given in Section 4.9.
If multiple sources of data are used, source information should be indicated in
the L2P variable source_of_sea_ice_fraction as defined by the data provider
and as described in detail in Section 7.2.11, and
the source variable attribute of sea_ice_fraction shall have the value
source_of_sea_ice_fraction. In addition, the units of all sources used in the
file shall be identical.
The variable attribute sea_ice_treatment shall specify how
the sea ice information has been treated by the data provider. Valid options
are: “Use unmodified (one source)”, “use unmodified (multiple ice sources)”,
or “modified using onboard sensors”.
The variable sea_ice_fraction will be included with the format requirements
shown in Table 7.13.
Table 7.13 CDL example description of sea_ice_fraction variable#
Storage type
Name
Description
Unit
byte
sea_ice_fraction
fractional of sea ice contamination in a given pixel. Ranges from 0 to 1.
A single source of sea ice fraction data is shown in this example which is
reported as sea_ice_fraction:source="REMSS_AMSRE_V5" following the
ancillary data naming conventions specified in Section 4.9. Since
all of ice values have the same time, the attribute time_offset is used
instead of the variable sea_ice_fraction_dtime_from_sst.
The variable sea_ice_fraction_dtime_from_sst reports the time difference
between sea ice fraction data from SST measurement in hours. This variable is
mandatory when multiple sources of sea_ice_fraction are used.
If only one source is used, simply set a variable attribute time_offset in
sea_ice_fraction variable, as the difference time in hours.
The variable sea_ice_fraction_dtime_from_sst shall be included with the format
requirements shown Table 7.14.
In the case of an analysis field, this should be the central (mean) time of an
integrated value. If all of the values are the same, this variable is not
required. Instead, use the variable level attribute named time_offset with
the variable sea_ice_fraction. The attribute time_offset should store
the difference in hours between the sea ice analysis time and the reference
time, stored in the variable time.
Table 7.14 CDL example description of sea_ice_fraction_dtime_from_sst variable#
Storage type
Name
Description
Unit
byte
wind_speed_dtime_from_sst
This variable reports the time difference between sea ice fraction data from SST measurement in hours.
hour
byte sea_ice_fraction_dtime_from_sst(time, nj, ni) ;
sea_ice_fraction_dtime_from_sst:_FillValue = -128b ;
sea_ice_fraction_dtime_from_sst:long_name = "time difference, in hours, of sea ice fraction measurement from sst measurement" ;
sea_ice_fraction_dtime_from_sst:units = "h" ;
sea_ice_fraction_dtime_from_sst:scale_factor = 0.1 ;
sea_ice_fraction_dtime_from_sst:add_offset = 0. ;
sea_ice_fraction_dtime_from_sst:coverage_content_type = "auxiliaryInformation" ;
sea_ice_fraction_dtime_from_sst:comment = "the hours between the sea ice fraction measurement and the SST observation" ;
sea_ice_fraction_dtime_from_sst:coordinates = "lat lon" ;
This variable is mandatory when multiple sources for sea_ice_fraction are
used. If only one source is used, instead simply set a variable attribute
sea_ice_fraction:sea_ice_fraction_dtime_from_sst=\<differencetimeinhours\>.
The source of data used to set the L2P ancillary data variable
sea_ice_fraction shall be indicated in the L2P variable
source_of_sea_ice_fraction when more than one source of sea ice fraction data
is used in the L2P product.
When only one source is used, this variable is not needed and the appropriate
text string indicating the source is placed in the source attribute of the
sea_ice_fraction variable.
For multiple sources, the GDS-2.1r0 requires the following:
The variable in question should contain an attribute called
flag_meanings and another one called flag_values. The flag_values
attribute shall contain a comma-separated list of the numeric codes for
the sources of data used whose order matches the comma-separated text
strings in the flag_meanings attribute.
These text strings and numeric codes do not need to be unique across
different data sets or even ancillary variables, but must be consistent
within a given variable and clearly specified within each netCDF variable
and its attributes. A best practice for naming the text strings in
provided in Section 4.9.
instead of using a _FillValue attribute and value for missing data, it is
recommended to set missing pixel values to 0 and add the corresponding
no_data meaning in flag_meanings attribute.
The variable source_of_sea_ice_fraction shall conform to the format
requirements shown in Table 7.15.
Table 7.15 CDL example description of source_of_sea_ice_fraction variable#
Storage type
Name
Description
Unit
byte
source_of_sea_ice_fraction
Source(s) of sea ice values
None
byte source_of_sea_ice_fraction(time, nj, ni) ;
source_of_sea_ice_fraction:long_name = "sources of sea ice fraction" ;
source_of_sea_ice_fraction:flag_meanings = "no_data CE-NSIDC-AMSRE-V3 ICE-ECMWF-Forecast-V3" ;
source_of_sea_ice_fraction:flag_values = 0b, 1b, 2b ;
source_of_sea_ice_fraction:coverage_content_type = "auxiliaryInformation" ;
source_of_sea_ice_fraction:comment = "This variable provides a pixel by pixel description of where the sea ice fraction were derived from." ;
source_of_sea_ice_fraction:coordinates = "lat lon" ;
In this example, flag_meanings and flag_values contain strings and
numeric codes provided by the data provider according to the best practices
specified in Section 4.9.
The L2P variable aerosol_dynamic_indicator contains an indicator of potential
atmospheric aerosol contamination of infrared satellite SST data.
Infrared-absorbing atmospheric aerosols are a major source of error in
satellite-derived sea surface temperature retrievals. Atmospheric aerosol, such
as Saharan dust outbreaks, volcanic eruptions or from coastal mega cities causes
errors in the atmospheric correction of top of the atmosphere radiances when
retrieving SST from infrared and visible band data sets. A systematic bias in
the tropical North Atlantic Ocean and Arabian Sea due to desert dust outflows in
those regions is apparent.
An aerosol indicator (e.g., derived from satellite measurements or models)
value is assigned to the L2P variable aerosol_dynamic_indicator for each
corresponding infrared retrieved SST measurement pixel using data chosen
by the data provider to indicate aerosol contamination. The aerosol
indicator data nearest in space and time to the input pixel SST value
should be used. In the case of microwave SST measurements there is no
requirement to include the aerosol_dynamic_indicator L2P variable as
microwave SST retrievals are not affected by atmospheric aerosols. However,
microwave SST data providers may include aerosol_dynamic_indicator in an
L2P product.
If a single source of data is used in the L2P variable
aerosol_dynamic_indicator, the L2P variable source_of_adi is not
required and instead the source variable attribute value in
aerosol_dynamic_indicator is sufficient. It shall be a single source
text string defined by the data provider using the text string naming best
practice given in Section 4.9. If all the times have the same
value, then using a variable attribute time_offset with variable
aerosol_dynamic_indicator is sufficient and the variable
adi_dtime_from_sst is not required.
If multiple sources of ADI information are used then, the source
variable attribute of aerosol_dynamic_indicator variable shall have the
value source_of_adi. In addition, the units of all sources used in the
file shall be identical.
The difference in time expressed in hours between the time of SST measurement
and the time of aerosol indicator data should be entered into the L2P variable
adi_dtime_from_sst as described in Section 7.2.13. In
the case of an analysis field, this should be the central (mean) time of an
integrated value.
If the variable aerosol_dynamic_indicator is provided in an L2P product,
it shall be included with the format requirements shown in the
Table 7.16.
Table 7.16 CDL example description of aerosol_dynamic_indicator variable#
Storage type
Name
Description
Unit
byte
aerosol_dynamic_indicator
Indicator of potential aerosol contamination of infrared satellite data
Provider defined
byte aerosol_dynamic_indicator(time, nj, ni) ;
aerosol_dynamic_indicator:_FillValue = -128b ;
aerosol_dynamic_indicator:long_name = "aerosol dynamic indicator" ;
aerosol_dynamic_indicator:units = "1" ;
aerosol_dynamic_indicator:source = "ADI-NAVO-SDI-V2" ;
aerosol_dynamic_indicator:comment = "Estimate of the potential for aerosol contamination based on the NAVO SDI_V2 product, in counts" ;
aerosol_dynamic_indicator:coverage_content_type = "auxiliaryInformation" ;
aerosol_dynamic_indicator:time_offset = 3. ;
aerosol_dynamic_indicator:coordinates = "lat lon" ;
aerosol_dynamic_indicator:add_offset = 0. ;
aerosol_dynamic_indicator:scale_factor = 0.1 ;
A single source of aerosol_dynamic_indicator has been used in this example
indicated using the aerosol_dynamic_indicator:source and are defined by the
data provider using the ancillary data naming best practice given in Section 4.9. Since all of the values have the same time, the
attribute time_offset is used instead of the variable
aerosol_sst_dtime_from_sst to indicate the offset in hours from the
reference variable sst_dtime.
The variable adi_dtime_from_sst reports the time difference between aerosol
indicator data from input L2 SST measurement in hours. The variable
adi_dtime_from_sst shall be included in L2P products with the format
requirements shown in the Table 7.17. In
the case of an analysis field, this should be the central (mean) time of an
integrated value. If all of the values are the same, this variable is not
required. Instead, use the variable level attribute named time_offset with
the variable aerosol_dynamic_indicator.
Table 7.17 CDL example description of adi_dtime_from_sst variable#
Storage type
Name
Description
Unit
byte
adi_dtime_from_sst
Time difference of aerosol dynamic indicator data from SST measurement in hours
hour
byte sea_ice_fraction_dtime_from_sst(time, nj, ni) ;
sea_ice_fraction_dtime_from_sst:_FillValue = -128b ;
sea_ice_fraction_dtime_from_sst:long_name = "time difference, in hours, of sea ice fraction measurement from sst measurement" ;
sea_ice_fraction_dtime_from_sst:units = "h" ;
sea_ice_fraction_dtime_from_sst:scale_factor = 0.1 ;
sea_ice_fraction_dtime_from_sst:add_offset = 0. ;
sea_ice_fraction_dtime_from_sst:coverage_content_type = "auxiliaryInformation" ;
sea_ice_fraction_dtime_from_sst:comment = "the hours between the sea ice fraction measurement and the SST observation" ;
sea_ice_fraction_dtime_from_sst:coordinates = "lat lon" ;
The source of data used to set the L2P ancillary data variable
aerosol_dynamic_indicator shall be indicated in the L2P variable
source_of_adi when more than one source of SSI data is used in the L2P
product.
When only one source is used, this variable is not needed and the
appropriate text string indicating the source is placed in the sources attribute
of the aerosol_dynamic_indicator variable.
For multiple sources, The variable in question should contain an attribute
called flag_meanings and another one called flag_values. The
flag_values attribute shall contain a comma-separated list of the numeric
codes for the sources of data used whose order matches the space-separated text
strings in the flag_meanings attribute. These text strings and numeric
codes do not need to be unique across different data sets or even ancillary
variables, but must be consistent within a given variable and clearly
specified within each netCDF variable and its attributes. A best practice
for naming the text strings in provided in Section 4.9.
instead of using a _FillValue attribute and value for missing data, it is
recommended to set missing pixel values to 0 and add the corresponding
no_data meaning in flag_meanings attribute.
The variable source_of_adi shall conform to the with the format requirements
shown in the Table 7.18.
Table 7.18 CDL example description of source_of_adi variable#
Storage type
Name
Description
Unit
byte
source_of_adi
Sources of aerosol dynamic indicator values
None
byte source_of_adi(time, nj, ni) ;
source_of_adi:_FillValue = -128b ;
source_of_adi:long_name = "sources of aerosol dynamic indicator" ;
source_of_adi:flag_meanings = "no_data AOD-NAAPS-ADI SDI-OSISAF-ADI" ;
source_of_adi:flag_values = 0b, 1b, 2b ;
source_of_adi:comment = "This variable provides a pixel by pixel description of where aerosol optical depth were derived from" ;
source_of_adi:coverage_content_type = "auxiliaryInformation" ;
source_of_adi:coordinates = "lat lon" ;
In this example, flag_meanings and flag_values contain strings and numeric
codes provided by the data provider according to the best practices specified
in Section 4.9.
Specify the type of input SST data (either infrared or passive microwave
instrument derived),
Pass through native flags from the input L2 SST data set and
Record any additional information considered important for the user of an L2P
data set.
The L2P variable l2p_flags holds Boolean (single bit) codes detailed in its
flag_meanings and flag_masks attributes, and split into two sections:
The first 6 bits of the L2P variable l2p_flags are generic flags that are
common to all L2P data files as defined in the Table 7.19
Bits 6-15 are defined by the L2P data provider and are specific to each L2
input data stream
Table 7.19 List of bits composing the l2P_flags variable#
Bit
Common flags
0
Set if passive microwave data (not set is assumed to be infrared)
1
Set if over land (not set is assumed to be ocean)
2
Set if pixel is over ice
3
Set if pixel is over a lake (if known)
4
Set if pixel is over a river (if known)
5
Reserved for future data
6-15
Defined by L2 data provider
The flag_meanings attribute shall contain a space-separated list of
(string with no space) descriptions for each distinct flag value. For
descriptions containing multiple words, the words shall be linked
by underscores.
The flag_masks attribute shall contain a comma-separated list of (numeric)
mask values that isolate the bit or bits that encode each flag value, whose
order matches that of the flag_meanings values.
It is recommended not to use _FillValue attribute as it is prone to
misinterpretation of the bit mask.
Bit 0 of the L2P l2p_flags is used to record if an input pixel SST is
derived from an infrared satellite sensor or a passive microwave sensor. If
an input pixel is derived from a passive microwave sensor, bit 0 of the L2P
l2p_flags variable should be set to 1. By not setting this flag the pixel is
assumed to be from an infrared sensor.
Bit 1 of the L2P l2p_flags variable is used to record if an input
pixel is over land or ocean surfaces. If an input pixel is classified as
land covered bit 1 of the L2P l2p_flags variable should be set to equal 1.
By not setting this flag the pixel is assumed to be classified as over ocean.
Bit 2 of the L2P l2p_flags variable is used to record if an input pixel
records ice contamination. If an input pixel is classified as ice
contaminated bit 2 of the L2P l2p_flags variable should be set to 1.
Bit 3 of the L2P l2p_flags variable is used to record if an input pixel
contains any part of a lake, as defined by the GHRSST definition of lakes
(mask). If an input pixel contains any part of a lake, as defined by the
GHRSST definition of lakes (mask), bit 3 of the L2P l2p_flags variable
should be set to 1.
Bit 4 of the L2P l2p_flags variable is optionally used to record if an
input pixel contains any part of a river, as defined by the GHRSST
definition of rivers (mask). If an input pixel contains any part of a
river, as defined by the GHRSST definition of rivers (mask), bit 4 of the
L2P l2p_flags variable should be set to 1.
Flags or other information provided with the input L2 SST data should be defined
and assigned to the l2p_flags variable using bits 6-15 of the L2P variable
l2p_flags. It is recommended to use single bits for any information, no
combination of multiple bits. If that is not possible, then an additional
experimental byte field should be used instead. Definitions for bits 6-15, if
used, should be given using the variable comment attribute.
The L2P variable l2p_flags shall be included in GDS-2.1r0 L2P
data files with the format requirements shown in Table 7.20.
Table 7.20 CDL example description of source_of_adi variable#
Storage type
Name
Description
Unit
short
l2p_flags
The variable l2p_flags is used to (a) specify the type of input SST data (either infrared or passive microwave instrument derived), (b) pass through native flags from the input L2 SST data set and (c) record any additional information considered important for the user of an L2P data set
None
short l2p_flags(time, nj, ni) ;
l2p_flags:long_name = "L2P flags" ;
l2p_flags:flag_meanings = "microwave land ice lake" ;
l2p_flags:flag_masks = 1s, 2s, 4s, 8s ;
l2p_flags:comment = "These flags are important to properly use the data." ;
l2p_flags:coverage_content_type = "qualityInformation" ;
l2p_flags:coordinates = "lat lon" ;
The L2P variable quality_level provides an indicator of the overall quality
of an SST measurement in an L2P file. The GDS requires the following:
The L2P variable quality_level shall use an incremental scale from 0 to
5 to provide the user with an indication of the quality of the L2P SST data,
reflecting the CEOS QA4EO (Quality Indicator) guidelines. The value 0
shall be used to indicate missing data and the value 1 shall be used to
indicate invalid data (e.g. cloud, rain, too close to land - under no conditions
use this data). The remaining values from 2-5 are set at the discretion of
the L2P provider with the proviso that the value 2 shall be used to
indicate the worst quality of usable data and the value 5 shall be used to
indicate the best quality usable data. The L2P provider is required to provide
a description of the quality levels provided as part of the product
documentation.
The L2P variable quality_level reflects the quality of SST data from a
single sensor and does not provide an indication of the relative quality
between sensors.
The L2P variable quality_level shall be included with the format
requirements shown in the Table 7.21.
We recommend not to use the _FillValue attribute but rather to use the
value 0 to fill in missing data pixels.
Table 7.21 CDL example description of quality_level variable#
Storage type
Name
Description
Unit
byte
quality_level
Overall indicator of SST measurement quality
n/a
byte quality_level(time, nj, ni) ;
quality_level:_FillValue = -128b ;
quality_level:long_name = "quality level of SST pixel" ;
quality_level:flag_meanings = "no_data bad_data worst_quality low_quality acceptable_quality best_quality" ;
quality_level:flag_values = 0b, 1b, 2b, 3b, 4b, 5b ;
quality_level:comment = "These are the overall quality indicators and are used for all GHRSST SSTs" ;
quality_level:coverage_content_type = "qualityInformation" ;
quality_level:coordinates = "lat lon" ;
Sea surface temperature retrievals from satellite instruments degrade as the
sensor zenith angle increases. Measurements made with high viewing angles
relative to nadir appear to be considerably colder than they are in reality. The
L2P variable satellite_zenith_angle contains the calculated satellite zenith
angle (measured at the Earth’s surface between the satellite and the zenith) for
the input L2 SST based on the satellite geometry at the time of SST data
acquisition.
The GDS L2P variable satellite_zenith_angle is an optional field that may be
provided by a data provider. The satellite zenith angle for each input pixel
measurement should be recorded in the L2P variable satellite_zenith_angle
having a range of 0° to +90°.
If the L2P variable satellite_zenith_angle is included in a L2P data product
it shall conform to the format requirements shown in
Table 7.22.
Table 7.22 CDL example description of satellite_zenith_angle variable#
Storage type
Name
Description
Unit
byte or short
satellite_zenith_angle
Calculated satellite zenith angle (measured at the Earth’s surface between the satellite and the local zenith) for the input L2 SST based on the satellite geometry at the time of SST data acquisition. Ranges from 0 to 90 degrees.
angular_degree
byte satellite_zenith_angle(time, nj, ni) ;
satellite_zenith_angle:_FillValue = -128b ;
satellite_zenith_angle:long_name = "satellite zenith angle" ;
satellite_zenith_angle:units = "angular_degree" ;
satellite_zenith_angle:comment = "The satellite zenith angle at the time of the SST observations." ;
satellite_zenith_angle:coverage_content_type = "auxiliaryInformation" ;
satellite_zenith_angle:standard_name = "sensor_zenith_angle" ;
satellite_zenith_angle:coordinates = "lat lon" ;
satellite_zenith_angle:add_offset = 0. ;
satellite_zenith_angle:scale_factor = 1. ;
The L2P variable solar_zenith_angle contains the calculated solar zenith
angle (the angle between the local zenith and the line of sight to the sun,
measured at the Earth’s surface) for the input L2 SST based on the satellite
geometry at the time of SST data acquisition. Solar zenith angle is a function
of time, day number and latitude.
The GDS L2P variable solar_zenith_angle is an optional field that may be
provided by a data provider. The solar zenith angle for each input pixel
measurement should be recorded in the L2P variable solar_zenith_angle having
a range of 0° to 180°. If the L2P variable solar_zenith_angle is included in
a L2P data product it shall conform to the format requirements shown in
Table 7.23.
Table 7.23 CDL example description of solar_zenith_angle variable#
Storage type
Name
Description
Unit
byte or short
solar_zenith_angle
Calculated solar zenith angle (measured at the Earth’s surface between the sun and the local zenith) for the input SST based on the solar geometry at the time of SST data acquisition. Ranges from 0 to 180 degrees.
angular_degree
byte solar_zenith_angle(time, nj, ni) ;
solar_zenith_angle:_FillValue = -128b ;
solar_zenith_angle:long_name = "solar zenith angle" ;
solar_zenith_angle:units = "angular_degree" ;
solar_zenith_angle:comment = "The solar zenith angle at the time of the SST observations." ;
solar_zenith_angle:coverage_content_type = "auxiliaryInformation" ;
solar_zenith_angle:standard_name = "solar_zenith_angle" ;
solar_zenith_angle:coordinates = "lat lon" ;
solar_zenith_angle:add_offset = 90. ;
solar_zenith_angle:scale_factor = 1. ;
Surface Solar Irradiance (SSI) data were originally required within the GDS 1.6
to assess the magnitude and variability of significant diurnal SST variations,
for use in diurnal variability correction schemes, for use in L4 SST analysis
procedures and to interpret the relationship between satellite and in situ SST
data. In the GDS-2.1r0, it is an optional variable. Ideally a near
contemporaneous SSI measurement from satellite sensors should be used but this
is impossible for all areas due to the limited number of geostationary satellite
sensors available. As a surrogate for a measured SSI value, analysis estimates
may be used.
Surface solar Irradiance (SSI) data may be assigned to each L2P SST measurement
pixel using the variable surface_solar_irradiance.
An integrated down-welling SSI measurement (e.g., derived from satellite
measurements) should be assigned to each SST pixel value using the
surface_solar_irradiance L2P variable. The SSI measurement nearest in space
and time before the input pixel SST value should be used. If no SSI measurement
is available, an integrated SSI value derived from an analysis system nearest in
space and time to the SST measurement should be used to set the value of
surface_solar_irradiance.
The difference in time expressed in hours between the time of SST measurement
and the time of surface solar irradiance data should be entered into the L2P
confidence data variable ssi_dtime_from_sst. In the case of an analysis
field, this should be the central (mean) time of an integrated value. If all of
the values have the same time, the attribute time_offset is used instead of
the variable ssi_dtime_fraction_dtime_from_sst. The attribute time_offset
should store the difference in hours between the surface_solar_irradiance
and the reference time, stored in the variable time.
If a single source of data is used in the L2P variable
surface_solar_irradiance, the L2P variable source_of_ssi is not required
and instead the surface_solar_irradiance:source attribute value is sufficient.
It shall be a single source text string defined by the data provider using the
text string naming best practice given in Section 4.9.
If multiple sources of data are used, source information should be indicated in
the L2P variable source_of_ssi as defined by the data provider and as
described in detail in Table 7.24. Then,
the surface_solar_irradiance:source attribute shall have the value
source_of_ssi.
The L2P variable surface_solar_irradiance may be included by a data provider
with the format requirements shown in Table 7.24.
Table 7.24 CDL example description of surface_solar_irradiance variable#
Storage type
Name
Description
Unit
byte
surface_solar_irradiance
Near contemporaneous integrated Surface Solar Irradiance (SSI) data.
\(W m^{-2}\)
byte surface_solar_irradiance(time, nj, ni) ;
surface_solar_irradiance:long_name = "surface solar irradiance" ;
surface_solar_irradiance:standard_name = "surface_downwelling_spherical_irradiance_in_sea_water" ;
surface_solar_irradiance:units = "W m-2" ;
surface_solar_irradiance:coverage_content_type = "auxiliaryInformation" ;
surface_solar_irradiance:comment = "The surface solar irradiance as close to the SST observation times as possible" ;
surface_solar_irradiance:scale_factor = 1.36 ;
surface_solar_irradiance:add_offset = 127. ;
surface_solar_irradiance:source = "SSI-MSG_SEVIRI-V1" ;
surface_solar_irradiance:time_offset = 2. ;
surface_solar_irradiance:coordinates = "lat lon" ;
A single source of SSI data is shown in this example which is reported as
surface_solar_irradiance:source="SSI-MSG_SEVIRI-V1" The text string has been
defined by the data provider using the text string naming best practice given
in Section 4.9. Since all of the SSI values have the same time, the
attribute time_offset is used instead of the variable ssi_dtime_from_sst.
Optional (Mandatory only if multiple observation time for
surface_solar_irradiance are provided).
The variable ssi_dtime_from_sst reports the time difference between SSI data
from SST measurement in hours. The variable ssi_dtime_from_sst shall be
included with the format requirements shown in Table 7.25.
In the case of an analysis field, the central (mean) time of an integrated value
should be used.
If all of the values are the same, this variable is not required. Instead, use
the variable level attribute named time_offset with the variable
surface_solar_irradiance.
Table 7.25 CDL example description of ssi_dtime_from_sst variable#
Storage type
Name
Description
Unit
byte
ssi_dtime_from_sst
This variable reports the time difference between SSI data from SST measurement in hours
hour
byte ssi_dtime_from_sst(time, nj, ni) ;
ssi_dtime_from_sst:_FillValue = -128b ;
ssi_dtime_from_sst:long_name = "time difference, in hours, of surface solar irradiance measurement from sst measurement" ;
ssi_dtime_from_sst:units = "h" ;
ssi_dtime_from_sst:scale_factor = 0.1 ;
ssi_dtime_from_sst:add_offset = 0. ;
ssi_dtime_from_sst:coverage_content_type = "auxiliaryInformation" ;
ssi_dtime_from_sst:comment = "the hours between the surface solar irradiance measurement and the SST observation" ;
ssi_dtime_from_sst:coordinates = "lat lon" ;
Optional (Mandatory only if multiple sources for surface_solar_irradiance
are provided).
The source of data used to set the L2P ancillary data variable
surface_solar_irradiance shall be indicated in the L2P variable source_of_ssi
when more than one source of SSI data is used in the L2P product. When only one
source is used, this variable is not needed and the appropriate text string
indicating the source is placed in the source attribute of the
surface_solar_irradiance variable.
For multiple sources, the variable source_of_ssi should contain an attribute
called flag_meanings and another one called flag_values. The flag_values
attribute shall contain a comma-separated list of the numeric codes for the
sources of data used whose order matches the space-separated text strings in
the flag_meanings attribute.
These text strings and numeric codes do not need to be unique across different
data sets or even ancillary variables, but must be consistent within a given
variable and clearly specified within each netCDF variable and its attributes. A
best practice for naming the text strings in provided in
Section 4.9.
instead of using a _FillValue attribute and value for missing data, it is
recommended to set missing pixel values to 0 and add the corresponding
no_data meaning in flag_meanings attribute.
The variable source_of_ssi shall conform to the format requirements shown
in the Table 7.26.
Table 7.26 CDL example description of source_of_ssi variable#
Storage type
Name
Description
Unit
byte
source_of_ssi
Sources of surface solar irradiance values
code
byte source_of_ssi(time, nj, ni) ;
source_of_ssi:long_name = "sources of surface solar irradiance" ;
source_of_ssi:flag_meanings = "no_data SSI-MSG_SEVIRI-V1 SSI-NOAA-GOES_E-V1 SSI-NOAA-GOES_W-V1 SSI-ECMWF-V1 SSI-NCEP-V1 SSI-NAAPS-V1 spare" ;
source_of_ssi:flag_values = 0b, 1b, 2b, 3b, 4b, 5b, 6b, 7b ;
source_of_ssi:coverage_content_type = "auxiliaryInformation" ;
source_of_ssi:comment = "This variable provides a pixel by pixel description of where the surface solar irradiances were derived from." ;
source_of_ssi:coordinates = "lat lon" ;
In this example, flag_meanings and flag_values contain code data provided
by the data provider according to the best practices specified
in Section 4.9. An example of these codes is given in the
Table 7.27.
Table 7.27 Example text string and numeric codes used to identify the sources of data in surface_solar_irradiance:sources and source_of_ssi#
Numeric Code
Text String
Sources of surface solar irradiance Description
0
no_data
No surface solar irradiance set
1
SSI-MSG_SEVIRI-V1
SSI from Meteosat Second Generation SEVIRI instrument (EUMETSAT OSI-SAF
2
SSI-NOAA-GOES_E-V1
GOES_E SSI data from NOAA
3
SSI-NOAA-GOES_W-V1
GOES_W SSI data from NOAA
4
SSI-ECMWF-V1
SSI data from European Centre for Medium Range Weather Forecasting
5
SSI-NCEP-V1
SSI data from NOAA’s National Center for Environmental Prediction
6
SSI-NAVY-NAAPS-V1
SSI data from the US Navy Atmospheric aerosol Prediction system
7
Spare to be defined as required
7.2.22. Optional experimental L2P variables included by data provider#
Flexibility of L2P product content is provided through the netCDF API, which
allows fully self-describing fields and additional L2P variables may be included
by L2P data providers if they are considered relevant for L2P users. The GDS-2.1r0
also permits the inclusion of R&D variables (e.g. channel radiance data sets,
estimates of Chlorophyll A, fields that facilitate flagging of diurnal
variability, etc.) and 32 bytes per pixel are available in total for
optional/experimental variables in any combination (i.e., variables can be
defined as 32 x byte, 16 x short, 3 x int + 4 x byte, etc). The use of
optional/experimental variables provides a limited amount of flexibility within
the GDS-2.1r0 for regional user requirements while maintaining an overall upper
limit on GDS-2.1r0 L2P products for data management groups and archive scaling. In
exceptional cases a waiver on the 32 byte ceiling can be requested to extend up
to 64 bytes per pixel.
The GDS-2.1r0 issues the following guidance on the inclusion of optional or
experimental variables within L2P data products:
The sum total of all experimental variables shall not increase L2P record
size by more than 32 bytes per SST pixel. A waiver can be requested
for higher amounts up to 64 bytes.
CF-1.7 or later compliance should be maintained for all
optional/experimental variables. Where available, a standard_name
attribute should be used.
It is permitted to use a provider defined coordinate variable associated
with experimental fields but this shall be documented in data provider
documentation.
Time difference data (dtime values) should be provided for variables when
appropriate.
The source of data should be indicated: in the single source case as a
variable attribute; as a dedicated variable when mixed data sources are
present.
Use of experimental variables requires clear documentation by the GHRSST
producer. They shall provide adequate documentation that describes each
variable following the CDL examples provided in this document.
The variable attribute comment shall be used to provide a URL link to a
full description of each data producer defined variable included in the
L2P product.
Experimental L2P variables if present in an L2P product will be included
with the minimum format requirements shown in Table 7.28
Additional global variables may be declared within the L2P product.
Table 7.28 CDL template for data provider defined L2P variables#
Storage type definition
Variable name definition
Description
Unit
byte
Provide a variable name in lower case using underscore separators e.g. my_variable
Provide a description of my_variable stating content purpose and units
The following CDL has been generated for a L2P dataset derived from the VIIRS
sensor on NOAA-20 platform (https://doi.org/10.5067/GHV20-2PO28) . It includes a
number of optional and experimental variables.
8.1. Overview description of the GHRSST L3 data product#
GHRSST L3 data have been introduced to provide users with gridded, synthetic,
and potentially adjusted SST products, bringing added value with respect to the
original L2P but still allowing traceability to the original dataset. GHRSST L3
products do not use analysis or interpolation procedure to fill gaps where no
observations are available. The GHRSST L3 products include:
Un-collated data that represent a straightforward remapping of L2P GHRSST
data granules to a space grid without combining any observations from
overlapping orbits or times. Although in principle these data may or may not
be adjusted to a reference sensor, in practice the un-collated L3 will
normally be a remapped L2P dataset. For remapping best practices of L2P on
a grid, see Section 8.4.1.
Collated data that grid observations from a single instrument and a single
platform into space and/or time bins. These data may or may not be adjusted to
a reference sensor. For collating best practices, see
Section 8.4.2 and for adjustment best practices see
Section 8.4.3.
Super-collated data that combine observations from a multiple instruments
into a space-time grid. In this case, the adjustment to a common reference is
necessary to avoid heterogeneities in the resulting field. For best practices
concerning the creation of super collated files see
Section 8.4.4
As a result, the format of a L3 file will be able to cope with the three kinds
of L3 SST presented above. The L3 format will include the following parts:
In case the L3 is un-adjusted, a mandatory section containing the
original L2P information remapped onto the grid point: the original sea
surface temperature, quality level and SSES information. An optional
section including the remapping condition information may also be
provided. These files are essentially gridded L2P files.
In case the L3 is adjusted to a reference, the adjusted SST value must
be provided, together with the local bias to the reference, the error
generated by the adjustment processing, and the overall error resulting
from the combination of the SSES and the adjustment processing error.
In case the L3 is super-collated, the source of SST at each pixel is
mandatory.
Un-adjusted files: In the case of un-collated or collated un-adjusted L3
files the L3 file is derived from L2P data by a remapping process. The
remapping and collating best practices are given in
Section 8.4.1. Their content is thus identical to that
of the L2P, but complementary, optional information on the remapping conditions
may be provided.
Adjusted files: Collated files may or may not be adjusted, but a
super-collated file is necessarily adjusted. The super-collating and adjustment
best practices are described in Section 8.4.2 and
Section 8.4.3. The principle governing this format is to
allow traceability to the original L2P, while providing the best-adjusted SST
value. A first section (in blue in Table 8.1) reproduces the original
L2P SST and SSES information as in the un-adjusted version. The reference used
to adjust the SST must be given in the “reference” attribute of the
adjusted_sea_surface_temperature variable. The adjusted SST and some error
information are also mandatory. This information, in yellow in
Table 8.1, is:
adjusted_standard_deviation_error: the total error resulting from the
combination of the SSES error and the adjustment procedure error,
standard_deviation_to_reference_sst.
bias_to_reference_sst: the local value of the estimated difference between
the original SST and the reference SST
standard_deviation_to_reference_sst: an estimate of the error resulting
from the adjustment procedure. If the procedure consists of analysing a field
of differences of original SST and reference SST, the
standard_deviation_to_reference_sst will be the error of this analysis.
The GHRSST Science Team determined that 5 mandatory fields will form the core
data content of a GHRSST L3 data file. In addition to global attributes and
geo-location information, GHRSST producers must provide the following within
a L3 file:
Sea Surface temperature data (SST),
Time of SST measurement,
Bias and Standard Deviation error estimates for SST data,
Data quality.
There are a number of optional fields that may be used at the data provider’s
discretion that will form the core data content of a GHRSST data
file (Table 8.2).
The GHRSST L3 file contents are summarized in Table 8.1 below.
Table 8.1 Summary description of the contents within a GHRSST L3 data product#
netCDF File Contents
Description
Coordinate variables
Information to permit locating data on grids, as defined in Section 6
L2P Data record variables
Core and auxiliary variables as defined in Section 7.2
This table provides an overview of the GHRSST L3 product pixel data record that
should be created for each input data. Within GHRSST L3 data files, there are
many variables that are defined identically to their L2P counterparts. In
addition, there are several variables that are unique to L3. Both types are
listed below in Table 8.2. In the following sections, each
variable within the L3 data file that is unique to L3 is described in detail.
Table 8.2 Summary description of GHRSST L2P data records#
This variable is the original latitude of the contributing pixel in case of
remapping to the nearest pixel, or the average latitude of the contributing
pixels in case of averaging.
The variable or_latitude will be included either as a floating point
variable similarly to the grid latitude and longitude, or as a short variable,
with the format requirements shown in Table 8.3, if the required
precision is compatible.
Table 8.3 CDL example description of or_latitude variable#
Storage type
Name
Description
Unit
short or float
or_latitude
Original latitude of the satellite measurement
degree_north
short or_latitude(time, lat, lon) ;
or_latitude:_FillValue = -32768s ;
or_latitude:long_name = "original latitude of the SST value" ;
or_latitude:standard_name = "latitude" ;
or_latitude:units = "degree_north" ;
or_latitude:coverage_content_type = "coordinate" ;
or_latitude:authority = "CF-1.11, ACDD-1.3" ;
or_latitude:add_offset = 0. ;
or_latitude:scale_factor = 0.01 ;
This variable is the original longitude of the contributing pixel in case of
remapping to the nearest pixel, or the average longitude of the contributing
pixels in case of averaging.
The variable or_longitude shall be included either as a floating point
variable similarly to the grid latitude and longitude, or as a short variable,
with the format requirements shown in Table 8.4, if the
required precision is compatible.
Table 8.4 CDL example description of or_longitude variable#
This variable is the number of original pixels from the L2P contributing to
the binned (space and/or time) average.
The variable or_number_of_pixels shall be included with the format
requirements shown in Table 8.5.
Table 8.5 CDL example description of or_number_of_pixels variable#
Storage type
Name
Description
Unit
short
or_number_of_pixels
Number of pixels from the L2P contributing to the SST value
“1” (unitless)
short or_number_of_pixels(time, lat, lon) ;
or_number_of_pixels:_FillValue = -32768s ;
or_number_of_pixels:long_name = "original number of pixels from the L2Ps contributing to the SST value" ;
or_number_of_pixels:units = "1" ;
or_number_of_pixels:standard_name = "sea_surface_foundation_temperature number_of_observations" ;
or_number_of_pixels:coverage_content_type = "referenceInformation" ;
This variable represents the total error associated with the
adjusted_sea_surface_temperature variable. It represents the accumulated
error of the SST production (the sses_standard_deviation) and the SST
adjustment (standard_deviation_to_reference_sst).
The variable adjusted_standard_deviation_error shall be included with the
format requirements shown in Table 8.9.
Table 8.9 CDL example description of adjusted_standard_deviation_error variable#
Storage type
Name
Description
Unit
byte
adjusted_standard_deviation_error
Total error standard deviation estimate derived from SSES and adjustment method
K (kelvin)
byte adjusted_standard_deviation_error(time, lat, lon) ;
adjusted_standard_deviation_error:_FillValue = -128b ;
adjusted_standard_deviation_error:long_name = "standard deviation error based on L2P SSES and adjustment method" ;
adjusted_standard_deviation_error:units = "K" ;
adjusted_standard_deviation_error:coverage_content_type = "qualityInformation" ;
adjusted_standard_deviation_error:comment = "Cumulated errors of SSES and adjustment method" ;
adjusted_standard_deviation_error:scale_factor = 0.01 ;
adjusted_standard_deviation_error:add_offset = 1. ;
Mandatory and only applicable to super-collated (L3S) type files.
This variable represents the source(s) of SST data when merging the
values from different input datasets.
When only one source is used, this variable is not needed and the appropriate
text string indicating the source is placed in the source attribute of the
sea_surface_temperature variable.
For multiple sources, the GDS-2.1r0 requires the following:
The variable in question should contain an attribute called flag_meanings
and another one called flag_values. The flag_values attribute shall
contain a comma-separated list of the numeric codes for the sources of data
used whose order matches the comma-separated text strings in the
flag_meanings attribute.
These text strings and numeric codes do not need to be unique across different
data sets or even ancillary variables, but must be consistent within a given
variable and clearly specified within each netCDF variable and its attributes.
A best practice for naming the text strings in provided in Section 4.9.
In a super-collated file (L3S), the variable source_of_sst shall be included
with the format requirements shown in Table 8.12.
Table 8.12 CDL example description of source_of_sst variable#
The remapping procedure consists in remapping the original L2P in swath
projection onto a fixed grid. This remapping should preserve the traceability of
the SST at pixel level and keep the best quality data.
If the original and final grid resolutions are similar, the nearest pixel
remapping should be adopted. To do so, either a “source to target” or a “target
to source” approach may be used. The latter, target to source, which consists in
scanning the target grid points to find the nearest pixel in the source, is
recommended since it avoids creating holes in the remapped field.
If the original grid resolution is finer than the output grid,
Fig. 8.1 an averaging procedure can be adopted. For these cases the
best practice is to average the values of all pixels which overlap the product
cell entirely and which have a L2P confidence record quality_level value equal
to the highest encountered within the cell, to produce a single value.
Fig. 8.1 To illustrate the approach when the L3 product output grid is over-sampled by
the L2P input data. All pixels labeled p in the input data are possible
contributors to the value for new cell A.#
The following practices are recommended by the GDS:
In the case of a smaller L2P input pixel than the grid cell size, L3 data
product cell values are derived from an average of the L2P pixel which
completely overlap the product cell and which have a L2P quality record
quality_level value equal to the highest encountered within the cell,
to produce a single value.
For input pixels that straddle the boundary between output grid cells, a
weighting function may be applied to the input values according to the
degree of coverage of the output grid cell and according to the SSES.
Only the best quality original data within a grid cell should be averaged
to produce the resulting SST value, to preserve the homogeneity of the
SST quality (recommendation 1 above). In the case of averaging, the
number of contributors can be recorded as well as the sum of the SST
values and the sum of the square values of the SST. The SSES and
ancillary data (if needed, for instance if there may be more that one
SSES couple of values (bias and standard deviation) by quality level)
must be averaged accordingly: the sses_bias values are averaged
similarly as the SST values, the new sses_standard_deviation value is
the square root of the averaged squared values of the contributing
sses_standard_deviations. The averaging should account for the nature
of the original l2P_flags.
In the case of a larger pixel than the L3 grid cell size, 2 approaches
can be adopted:
The value of the L2P pixel is allocated to the grid cell the closest to
the pixel centre.
The output grid cell takes the value of the L2P pixel in which its
centre lies. In this case the original latitudes and longitudes of the
pixel must be recorded, to be able to detect where the original L2P
pixel value has been duplicated.
If the original grid resolution is larger than the output grid (e.g.,
microwave instruments), as illustrated in Fig. 8.2, the following
practices are recommended by the GDS:
Fig. 8.2 To illustrate the approach when the L3 output grid is under-sampled by the
L2P data. Either Grid cell C is assigned the value of pixel p, Or grid cell
A is assigned the value of pixel p and grid cell B is assigned the weighted
average of p and q provided they both have quality flags with the same rating.#
8.4.2. Collating Data from the Same Sensor and Platform#
The collating procedure consists of gathering over a unique grid several orbits
or slots (in the case of a geostationary satellite) of the same sensor on the
same platform. This process is often known as “binning” the data. The collating
procedure merges data with different times of observation.
For situations in which the collation is to be done for data collected within
the same day, two cases are met in practice: collation of consecutive orbits
in the case of data collected from polar orbiting sensors, or the merging of
consecutive slots in the case of geostationary satellites. In both cases
there may be multiple candidates for a grid cell.
a. To collate observations from overlapping orbits of the polar orbiting
sensors, the selection procedure should prioritize data first by using the
highest available quality data. If multiple observations share the same
highest quality, one of two approaches should be taken: either the
observation with the minimum satellite zenith angle should be selected, or
the observations should be averaged. If the minimum satellite zenith angle
approach is taken, the corresponding sses_bias and
sses_standard_deviation should be selected as well. If the averaging
approach is followed, the sses_bias and sses_standard_deviation should be
averaged similarly (note that the new sses_standard_deviation value is the
square root of the averaged squared values of the contributing
sses_standard_deviation values). Also in the case of averaging, it is good
practice to record the number of observations being averaged, the sum of the
SST values, and the sum of the squared SST values. These values can be stored
in the or_number_pixels, sum_sst, and sum_square_sst variables
listed in Sections and 8 and 9.
b. In the case of geostationary data, the selection procedure must prioritize
data showing the best quality level, and if equal, data closest to the
representative time (central time) of the L3 time window. In the case of
geostationary satellites, remapping is not a preliminary step to the
collating procedure.
If averaging over multiple days, only the best quality original data within a
grid cell should be averaged to produce the resulting SST value, to preserve
the homogeneity of the SST quality. The number of contributors can be
recorded (or_number_pixels) as well as the sum of the SST values (
sum_sst) and the sum of the square values of the SST (sum_square_sst).
The SSES values should be averaged accordingly: the sses_bias values are
averaged in the same manner as the SST values and the new
sses_standard_deviation value is the square root of the averaged squared
values of the contributing sses_standard_deviation values. The averaging
should preserve the nature of the original l2P_flags.
Most of individual sensors show regional biases resulting in limitations of the
applied algorithms. The objective of the adjustment procedure is to provide a
correction to these regional biases by comparison with a “reference sensor”,
supposedly free from such biases. A variety of sources can be adopted as
references in the adjustment procedure, ranging from AATSR or in situ
measurement to using a median of sensors approach. The adopted reference must be
recorded in the adjusted_sea_surface_temperature variable “reference”
attribute.
The adjustment procedure includes the following steps:
application of the SSES,
determination of the bias adjustment to the reference,
evaluation of the error of the adjustment procedure
Note
A skin to subskin conversion may be needed. In that case, please refer to
the STVAL recommendations. The type of the SST variables must be recorded in the
standard_names of the sea_surface_temperature and
adjusted_sea_surface_temperature variables. The bias adjustment value at
pixel and the error of the adjustment procedure must be recorded in the
corresponding variables (mandatory).
8.4.4. Super-Collating Data from Multiple Sensors and Platforms#
The building of a super-collated file takes place by merging adjusted collated
L3 files from various sensors over the same grid and over the same time window.
There is one input candidate file (and hence one candidate observation) per
sensor. There may be multiple candidates for a given grid cell originating from
different sensors. To make the selection from among the candidates, a “decision
tree” or selection hierarchy should be established a priori. This hierarchy
depends on the objective of the super-collation procedure, and may be quite
different for a moderate resolution (10km) super-collated over 24h aiming to
feed a foundation SST analysis and for a high resolution (2km) hourly subskin
SST super-collated aiming to feed a diurnal warming analysis, for example.
Because the hierarchy must be established based on the intended use of the
super-collated dataset that results, it is out of the scope of this document to
define any single hierarchy. However, the adopted hierarchy must be described in
the comment attribute of the adjusted_sea_surface_temperature variable.
In addition, it is mandatory to provide the source of the SST (source_of_sst)
at the grid cell level.
9.1. Overview description of the GHRSST L4 data product#
L4 products are the analyzed SST products, usually derived from GHRSST L2P
products. L4 data products should ideally be made available within the
GHRSST R/GTS framework to the user community within 24 hours.
L4 products include gap-free analyzed SST data together with a number of
ancillary fields that simplify interpretation and application of the SST
data. Data providers are responsible for providing documentation on their
analysis procedure. The common format of L4 products allows data users to
code with the security that as new SST data products are brought on-line,
very minimal code changes are required to make full use of a new L4 product.
Time previously spent on coding different I/O routines for each satellite
data set can be spent working with the data to produce results.
The GHRSST Science Team determined that there will be 4 mandatory fields
that form the core data content of a GHRSST L4 data file. In addition to global
attributes and geo-location information, producers must include the following
within a L4 file:
Sea Surface temperature data (SST)
Error estimates for SST data
Sea ice fraction (only and sea ice covered areas)
Land/sea/ice flag
In addition, there are a number of optional fields that may be used at the
data provider’s discretion.
The GHRSST L4 file contents are summarized in Table 9.1
below.
Table 9.1 Summary description of the contents within a GHRSST L4 data product#
Description
Required
Coordinate variables
Information to permit locating data on grids, as defined in Section 6
Data record variables
Core and auxiliary variables as defined in Table 9.2
Global Attributes
A collection of required global attributes describing general characteristics of the file, as defined in section Section 5.2
L4 analysed data products are derived from an analysis procedure implemented
at regular intervals (daily, six-hourly or other time periods). L4 data
products include SST, error statistics, sea ice fraction, land/sea/ice mask,
and other optional data for each grid-cell. A 6-byte experimental block
is available for data providers to test new aspects of the file or
information specific to the analysis system that will eventually transition
into a GHRSST standard L4 analysis field once tested.
Table 9.2 describes the format of GDS L4 variables that should be
created for each L4 grid cell. In the following sections, each variable
within the L4 data file is described in detail.
The variable analysed_sst will be included with the format requirements shown
in Table 9.3.
The data provider is responsible for providing GHRSST with documentation on
how the analysed SST is determined. Note that the RDAC should place the
_FillValue value in pixels that fall on land.
Table 9.3 CDL example description of analysed_sst variable#
The variable sea_ice_fraction will be included with the format requirements
shown in Table 9.5.
Some SST data are contaminated in part or wholly by sea ice and the L4 variable
sea_ice_fraction is used to quantify the fraction of an area contaminated
with sea ice. If the error estimates on the sea ice field are available, it
is recommended to provide this information as an experimental variable called
sea_ice_fraction_error.
Table 9.5 CDL example description of sea_ice_fraction variable#
The variable mask will be included with the format requirements shown in Table 9.6.
Table 9.6 CDL example description of mask variable#
Storage type
Name
Description
Unit
byte
mask
land/sea/ice/lake mask
none
byte mask(time, lat, lon) ;
mask:long_name = "land sea ice lake bit mask" ;
mask:flag_masks = 1b, 2b, 4b, 8b ;
mask:flag_meanings = "sea land lake ice" ;
Comments:
Comments
This is a land/sea/ice mask with the following bit values:
Bit 0:1 = water in grid
Bit 1:1 = land in grid
Bit 2:1 = optional, lake surface in grid
Bit 3:1 = sea ice
Bit 4:1 = optional, river surface in grid
Bits [5-7] spare
Note that the lake and river surface bit values are optional.
The source attribute should list any data product used in creating this
mask, a semi-colon separated list of identifiers
<provider>_<type_of_mask>_<version_mask>.
If the error estimates on the sea ice field are available, it is recommended
to provide this information as an optional field called
sea_ice_fraction_error. The data provider is responsible for providing
GHRSST with documentation on how sea_ice_fraction_error is estimated.
Table 9.7 CDL example description of sea_ice_fraction_error variable#
Storage type
Name
Description
Unit
byte
sea_ice_fraction_error
Fractional sea ice area concentration error
1
byte sea_ice_fraction_error(time, lat, lon) ;
sea_ice_fraction_error:_FillValue = -128b ;
sea_ice_fraction_error:long_name = "Sea ice area fraction error estimate" ;
sea_ice_fraction_error:units = "1" ;
sea_ice_fraction_error:source = "EUMETSAT SAF O&SI sea ice version 1.0" ;
sea_ice_fraction_error:scale_factor = 0.01 ;
sea_ice_fraction_error:add_offset = 0. ;
sea_ice_fraction_error:coverage_content_type = "auxiliaryInformation" ;
sea_ice_fraction_error:comment = "This will be different for each system" ;
9.6.1. Optional experimental L4 variables included by data provider#
Flexibility of L4 product content is provided through the netCDF API, which
allows fully self-describing fields and additional L4 variables may be included
by L4 data providers if they are considered relevant for L4 users. The GDS-2.1r0
also permits the inclusion of R&D variables (e.g. estimates of sea
ice fraction error, SST anomaly, etc.) and 6 bytes per pixel are available in
total for optional/experimental variables in any combination (i.e., variables
can be defined as 6 x byte, 3 x short, 2 x short + 2 x byte, etc). The use of
optional/experimental variables provides a limited amount of flexibility within
the GDS-2.1r0 for regional user requirements while maintaining an overall upper
limit on GDS-2.1r0 L4 products for data management groups and
archive scaling. In exceptional cases a waiver on the 6 byte ceiling can be
requested to extend up to 12 bytes per pixel.
The GDS-2.1r0 issues the following guidance on the inclusion of optional or
experimental variables within L4 data products:
The sum total of all experimental variables shall not increase L4 record
size by more than 6 bytes per SST pixel. A waiver can be requested
for higher amounts up to 12 bytes.
CF-1.7 or later compliance should be maintained for all
optional/experimental variables. Where available, a standard_name
attribute should be used.
It is permitted to use a provider defined coordinate variable associated
with experimental fields but this shall be documented in data provider
documentation.
Time difference data (dtime values) should be provided for variables when
appropriate.
The source of data should be indicated: in the single source case as a
variable attribute; as a dedicated variable when mixed data sources are
present.
Use of experimental variables requires clear documentation by the GHRSST
producer. They shall provide adequate documentation that describes each
variable following the CDL examples provided in this document.
The variable attribute comment shall be used to provide a URL link to a
full description of each data producer defined variable included in the
L4 product.
Experimental L4 variables if present in an L4 product will be included
with the minimum format requirements shown in Section 9.6
Additional global variables may be declared within the L4 product.
Striving to achieve a flexible naming convention that maintains consistency across processing levels and better serves user needs, the GDS uses a single form for all GHRSST data files. An overview of the format is presented below in Section 4.1 along with example filenames. Details on each of the filename convention components are provided in Section 4.2 through Section 4.8.
In addition, a best practice has been established for creating character strings used to describe GHRSST SST products and sources of ancillary data. These strings, and associated numeric codes for the SST products, are used within some GHRSST data files but are not part of the filename convention itself. The best practice is described in Section 4.9.
4.1. Overview of Filename Convention and Example Filenames#
The filenaming convention for the GDS 2.1r0 is shown below:
The variable components within braces (“< >”) are summarized in Table 4.1 below and detailed in the following sections. Note that dashes (“-“) are reserved to separate elements of the file name and should not be used in any GHRSST code or the <AdditionalSegregator> element. Example filenames are given later in this section. While no strict limit to filename length is mandated, RDACs are encouraged to keep the length to less than 240 characters to increase readability and usability.
The identifying date for this data set. See Section 4.2.
<IndicativeTime>
HHMMSS
The identifying time for this data set. The time used is dependent on the of the data set: L2P: start time of granule L3U: start time of granule L3C and L3S: centre time of the collation window L4 and GMPE: nominal time of analysis All times should be given in UTC. See Section 4.3.
The data processing level code (L2P, L3U, L3C, L3S, or L4)
The data processing level code, defined in Section 4.5.
<SSTType>
The type of SST data included in the file.
Conforms to the GHRSST definitions for SST, defined in Section 4.6.
<ProductString>
A character string identifying the SST product set. The string is used uniquely within an RDAC but may be shared across RDACs.
The unique “name” within an RDAC of the product line. See Section 4.9 for the product string lists, one each for L2P, L3, L4, and GMPE products. See Section 4.7.
<AdditionalSegregator>
Optional text to distinguish between files with the same . Dashes are not allowed within this element.
This text is used since the other filename components are sometimes insufficient to uniquely identify a file. For example, in L2P or L3U (un-collated) products this is often the original file name or processing algorithm. Note, underscores should be used, not dashes. For L4 files, this element should begin with the appropriate regional code as defined in Section . This component is optional but must be used in those cases were non-unique filenames would otherwise result.
<GDSVersion>
nn.n
Version number of the GDS used to process the file. For example, GDS-2.1 = “02.1”.
<FileVersion>
xx.x
Version number for the file, for example, “01.0”.
<FileType>
netCDF data file suffix (nc) or ISO metadata file suffix (xml)
Indicates this is a netCDF file containing data or its corresponding ISO-19115 metadata record in XML.
The above file contains GHRSST L2P blended SST data for 03 May 2007, from AVHRR LAC data collected from the NOAA-17 platform. The granule begins at 13:23:00 hours. It is version 1.0 of the file and was produced by the NAVO RDAC in accordance with the GDS 2.1r0. The <AdditionalSegregator> text is “SST_s0123_e0135”.
The above file was produced by the REMSS RDAC and contains collated L3 sub-skin SST data from the TMI instrument for 03 May 2007. The collated file has a centre time of at 11:01:53 hours. It is version 1.0 of the file and was produced according to GDS 2.1r0 specifications. Its <AdditionalSegregator> text is “tmi_20070503rt”.
The above file contains L4 foundation SST data produced at the UKMO RDAC using the OSTIA system. It is global coverage, contains data for 03 May 2007, was produced to GDS 2.1r0 specifications and is version 1.0 of the file. The nominal time of the OSTIA analysis is 12:00:00 hours.
The identifying date for this data set, using the format YYYYMMDD, where YYYY is the four-digit year, MM is the two-digit month from 01 to 12, and DD is the two-digit day of month from 01 to 31. The date used should best represent the observation date for the dataset.
The identifying time for this data set in UTC, using the format HHMMSS, where HH is the two-digit hour from 00 to 23, MM is the two-digit minute from 00 to 59, and SS is the two-digit second from 00 to 59. The time used is dependent on the <ProcessingLevel> of the data set:
L2P: start time of granule
L3U: start time of granule
L3C and L3S: centre time of the collation window
L4 and GMPE: nominal time of analysis
All times should be given in UTC and should be chosen to best represent the observation time for this dataset. Note: RDACs should ensure the applications they use to determine UTC proprerly account for leap seconds.
Codes used for GHRSST Regional Data Assembly Centres (RDACs) are available on the GHRSST website (https://www.ghrsst.org/resources/ghrsst-data-specification-gds-tables/). New codes are assigned by the GHRSST Data And Systems Technical Advisory Group (DAS-TAG) and entered into the table upon agreement by the GDAC, LTSRF, and relevant RDACs.
Satellite data processing level definitions can lead to ambiguous situations, especially regarding the distinction between L3 and L4 products. GHRSST identified the use of analysis procedures to fill gaps where no observations exist to resolve this ambiguity. Within GHRSST filenames, the <ProcessingLevel> codes are shown below in Table 4.2. GHRSST currently establishes standards for L2P, L3U, L3C, L3S, and L4 (GHRSST Multi-Product Ensembles known as GMPE are a special kind of L4 product for which GHRSST also provides standards).
Table 4.2 GHRSST Processing Level Conventions and Codes#
Level
Code
Description
Level 0
L0
Unprocessed instrument and payload data at full resolution. GHRSST does not make recommendations regarding formats or content for data at this processing level.
Level 1A
L1A
Reconstructed unprocessed instrument data at full resolution, time referenced, and annotated with ancillary information, including radiometric and geometric calibration coefficients and geo-referencing parameters, computed and appended, but not applied, to L0 data. GHRSST does not make recommendations regarding formats or content for data at this processing level.
Level 1B
L1B
Level 1A data that have been processed to sensor units. GHRSST does not currently make recommendations regarding formats or content for L1B data.
Level 2 Pre-processed
L2P
Geophysical variables derived from Level 1 source data at the same resolution and location as the Level 1 data, typically in a satellite projection with geographic information. These data form the fundamental basis for higher-level GHRSST products and require ancillary data and uncertainty estimates.
Level 3
L3U L3C L3S
Level 2 variables mapped on a defined grid with reduced requirements for ancillary data. Uncertainty estimates are still mandatory. Three types of L3 products are defined: Un-collated (L3U): L2 data granules remapped to a space grid without combining any observations from overlapping orbits Collated (L3C): observations combined from a single instrument into a space-time grid Super-collated (L3S): observations combined from multiple instruments into a space-time grid. Note that L3 GHRSST products do not use analysis or interpolation procedures to fill gaps where no observations are available.
Level 4
L4
Data sets created from the analysis of lower level data that result in gridded, gap-free products. SST data generated from multiple sources of satellite data using optimal interpolation are an example of L4 GHRSST products. GMPE products are a type of L4 dataset.
Note that within GHRSST, all L2P files require a full set of extensive ancillary data such as wind speeds and times of observation that are provided as ‘dynamic flags’ that users can manipulate to filter data according to their own quality criteria. L2P files form the basis of higher-level products and are often the best level products for data assimilation. The requirement for dynamic flags is particularly important in this context. Higher-level L3 products are often intended for general use or created for input to Level 4 analysis systems so the requirement for extensive ancillary data is reduced. Since some GHRSST RDACs only process data natively on grids (especially in the case of geostationary platform observations), the GDS 2.1r0 L3 specification is flexible enough to allow for the creation of L3 files which meet all the content requirements of a L2P file. In all L2P and L3 cases, bias and standard deviation uncertainty estimates are mandatory.
The distinction between L3 GHRSST and L4 GHRSST data is made primarily on whether or not any gap-filling techniques are employed, not on whether data from multiple instruments is used in the L3 product. If no gap filling procedure (such as optimal interpolation) is used, then the product remains a L3 GHRSST product. GHRSST defines three kinds of L3 files: un-collated (L3U), collated (L3C), and super-collated (L3S). If gap filling is used to fill all observations gaps, then the resulting gap-free data are considered L4 GHRSST data products.
In conjunction with the NetCDF Climate and Forecast (CF) community [AD-9] the GHRSST Science Team agreed on the CF standard names for “SST” shown in the following figure and described in more detail below. The names were first included in CF-1.3, and the current version of the standard name table can be found in [AD-8]. In addition, the GHRSST Science Team agreed to use the CF Naming Convention [AD-3] for variable names that do not already exist as part of the CF Convention. CF definitions are used in the GDS and across GHRSST and are shown schematically in Fig. 3.1. The different kinds of SST are detailed later in this section and the relevant <SSTType> codes to be used in the filenames are provided.
The SST codes and CF standard names defined above and used within GHRSST are summarized along with their key characteristics in Table 4.3.
The product strings are used within the GHRSST filename convention and within
the GHRSST unique data set codes described in Section 4.9. The
satellite platform and satellite sensor entries are also used in the netCDF
global attributes, platform and instrument GHRSST product files. See
Section 5.2 for more information on the required
global attributes.
In order to improve the consistency of these product strings across
producers, and avoid maintaining specific GHRSST tables, we recommend to use
the CEOS tables as vocabulary for satellite platform and satellite name:
It is possible for the preceding combination of filename components to result in a non-unique filename for any GHRSST product level. In those situations, the use of the <AdditionalSegregator> must be used to ensure each distinct file has a unique file name. In addition, RDACs are free to use this component to add other information to their file names. Some providers, for example, use the name of the original L1b file. Others enter start and stop times of the file in this component. Note that in the case of GHRSST L4 files the <AdditionalSegregator> element must begin with a code that specifies the approximate region covered by the SST analysis product. There are two primary reasons for this requirement, the first of which is to ensure uniqueness in the file names in the cases where an RDAC is using the same L4 analysis system (for example, “ODYSSEA”) to create products for multiple regions (for example, “GAL” (Galapagos Islands Region) and “MED” (Mediterranean Region)). The second reason is that users need to quickly identify at a glance the approximate domain of the L4 products. Users should note that the geographical coordinates associated with each area code are explicitly intended to be only approximate, and not strict. For example, an RDAC producing a near-global coverage data may choose to only produce data on a grid that extends to 85°S. Such a product would use the “GLOB” code. Users must retrieve the precise latitude and longitude limits directly from the L4 netCDF data files.
4.9. GHRSST Unique Text Strings and Numeric Codes#
This section describes the best practices that have been developed for creating unique text strings and numeric codes that are needed in various places within some GHRSST files. Note that these strings are not part of the filename convention described above, but, like filenames, they apply to all GHRSST product levels and so are described in this part of the GDS.
4.9.1. SST Variable Text Strings and Numeric Codes#
For each official GHRSST product, a unique numeric code and associated text string is defined. The string is listed in the global attribute id (see Section 8.2) for each netCDF file in the product collection. The unique numerical values and text strings for GHRSST SST datasets are established by agreement between the relevant RDAC, GDAC, and the LSTRF, following the Best Practice defined later in this section. The GHRSST L2P, L3, L4 and GMPE product specifications (Section 7, Section 8, Section 9, and 12, respectively) also require the providing RDAC to use these text strings directly within the netCDF global attribute source to indicate the sources of SST used to create the product. In the event that a non-GHRSST dataset is used as a source, as in the case of an L2P product that uses a Level 1 dataset as its source, it too must have an established text string following the best practice below (to the extent possible).
The associated numeric codes are used in some L3S files, which must describe the SST sources pixel-by-pixel in a variable named source_of_sst if more than one SST source is used. If only one source is used, the variable source_of_sst is not needed and instead the source is indicated simply by using the text string in the global attribute source (see Section 8.2 and Section 10.29) as indicated earlier.
4.9.2. Ancillary and Optional Variable Text Strings and Numeric Codes#
GHRSST L2P, L3, L4 and GMPE product specifications (Section 7, Section 8, Section 9, and 12, respectively) also require the providing RDAC to indicate text strings and associated numeric codes directly within the netCDF global and variable attributes for the sea surface temperature or ancillary sea ice fraction, aerosol depth indicator, climatologies, surface solar irradiance, wind speed, and when relevant, for optional and experimental variables. These text strings and codes do not need to be unique across different data sets, but must be consistent within a given data set and clearly specified within each netCDF file. In these cases, the variable in question should contain an attribute called flag_meanings together with a variable called flag_values. The flag_values attribute shall contain a comma-separated list of the numeric codes for the sources of data used whose order matches the space-separated text strings in the flag_meanings attribute.
4.9.3. Best Practice for Establishing Character Strings#
A best practice has been established for defining the text strings to be used in these GHRSST attributes. While a rigid standard for the text strings is not possible, the following best practice should be applied to the extent possible for GHRSST SST datasets and the ancillary and optional variables:
The definitions of the components match the definitions from the file naming convention, found in Table 4.1. The component <ProductVersion> is used to distinguish different versions of the same dataset and should be of the form x.y where x is the major and y is the minor version. For ancillary and optional variables, an attempt should be made to follow these conventions to the extent possible. If there is no appropriate GHRSST RDAC to use in the string, then it is recommended that a commonly used acronym for the centre responsible be used. It is recommended that the <AdditionalSegregator> should be one of ICE, ADI, CLIM, SSI, and WSP, for ancillary sea ice fraction, aerosol depth indicator, climatologies, surface solar irradiance, and wind speed variables, respectively.
Notethat many SST text strings not meeting this best practice were established under the GDS version 1 and are already in use.
These codes are used in the GHRSST Central Catalogue as product identifiers.
Contents
objects.inv 0000664 0001750 0001750 00000005613 14744715212 013435 0 ustar jfpiolle jfpiolle # Sphinx inventory version 2
# Project: Project name not set
# Version:
# The remainder of this file is compressed using zlib.
xڭ[n8}W<@ w\ړ Ĉ*-vjI!vz~xug{!M:U$bI}^>Շ;|bER%쮔=]]^IЌD_?
'Lrrp,oH*7eU`EJY&ҬdyH?P S
;b.KUiv*AlSQdbjeh+3feuʠW'% VS
$,l?ǀ ƣt'xq8$w¿U\P5quGL
*md<#'3ە,"_u[ 5eR9/^ Fi3MV`),[sFJ[hOv2ޫ. W1@ 3pU/#19s =q#AcØ0ˉ8ZƅRsg|oPřqԀBL*k.G8 *}l.< CҪƸ.4G
$ƙ3 'aNڮ BJ8Vlg2 ಪ&?D
#t
a٨>ŠUNp2-1<*R1>J"1WIZ;.y3;V-i]R֣m"3MlYJZQoa )~aAy#mҟKESDS JeaǰzpƵ[}LO { '#w|mY 2JK- dlI}8N@XҀs hpzM +c68 Ki_=3 h+r[?
{uDžSmygklj4xp!y/2Z}y?\ őv~s-j|:"R
s *
jYH<}0~H> 3+;c\t%W XUE|E=vQWƆ$ &&E'.EBw_Ard?inz[|HdWrsvvSV
OI)ezֳ&:jaa??0yI-:*ms?,};bayp!AcddTC KOhkSq=ԋ[j;0" 3r 2ܵS#K|EN [}y0p c.P|ugˁ\'NQҡ)s] (g+4 ,A<8X4;2d>D@4JC9:gyDPy1~wQOrtEtvtt-xMDRdX]Jb+Ԡ:k
}XbĿ[-1(CN2IBCw0 OU~qXX,縱
CPmlҊY"aQYOctֵj>Zϊl=OĻm{tdY$-f"{jvLJ"ݨʱ~S3=yc 7p$XOgWq/[/A_Z^eІ3J s=Gz sy D hX!`igA> =%bOc/1PODY1OPt_Z_#x;vD.ŀ}vHt&P/\XX# ?Q ˤGWcKj1EׂaGC`b/ICy&Kjk;H:Q,O0@nٶ, L xn MUR}X#q/E HQ+EQZ)w±RU#ngG"3.LI# k
^f`KceZ{iQRKշ3-W5+2^0xU=jTR <
k3!]p&mz9 PJ7J[+Zbj" m%X2Z
3[-Z۾w
vc l)ÚB|m8yƽ.hK
o`K *,O`iݩ~.Ww 7x1W%y' qt8VlDdd"eSWMJ{1Uc2>hȫE(r.uPjmf9
G=2|cebk
t7%pI~ϥd3ܠx kMTogiQ ^ȿ\l0+GY-oh< j\; r ׃z~yzwCh9
[>1! m^`vv {KϾ]'MNYlàarF"MAM,Ǥ0 TK
Mnӫ ~z҇ #h[ ?RjYuԋm^Q$c(kD?D/ :nyJ}S6hqWhxf"Q
Y/w7A=j + `?"֍d
A& j{Ә
O" :pe ̓uf n, overview.html 0000664 0001750 0001750 00000115274 14744715212 014027 0 ustar jfpiolle jfpiolle
2. Overview of GHRSST and the GDS-2.1r0 — The Recommended GHRSST Data Specification (GDS)
GHRSST[1] is an international consortium representing commercial
enterprises, academic institutions, research organizations, and operational
agencies that collaborate to provide accurate, high resolution, and consistently
formatted SST observations and analyses from space-based platforms.
This section briefly provides information on the importance of SST, an
overview and history of GHRSST, and context for understanding the
GDS-2.1r0.
Sea Surface Temperature at the ocean-atmosphere interface is a fundamental
variable for understanding, monitoring, and predicting fluxes of heat, momentum,
and gas at a variety of scales that determine complex interactions between
atmosphere and ocean. The ocean stores heat from the sun and redistributes it
from the tropical regions to higher latitudes and to the less dense atmosphere
regulating global weather and climate. Through the hydrological cycle the
coupled system controls terrestrial life by redistributing fresh water over the
land surface. From large ocean gyres and atmospheric circulation cells that fuel
atmospheric depression systems, storms and hurricanes with their attendant wind
waves and storm surges, to local scale phenomena such as the generation of sea
breezes and convection clouds, SST at the ocean-atmosphere interface has a
significant societal impact. Accurate knowledge of global SST distribution and
temporal variation at finer spatial resolution is needed as a key input to
numerical weather prediction (NWP) and numerical ocean prediction (NOP) systems
to constrain the modelled upper-ocean circulation and thermal structure at
daily, seasonal, decadal, and climatic time scales, for the exchange of energy
between the ocean and atmosphere in coupled ocean-atmosphere models, and as
boundary conditions for ocean forecasting models. Such models are widely used
operationally for various applications including maritime safety, military
operations, ecosystem assessments, fisheries support, and tourism.
In addition, well-defined and quantified error estimates of SST are also
required for climate time series that can be analysed to reveal the role of the
ocean in short and long term climate variability. A 30 year record of satellite
SST observations is available now, that grows on a daily basis. SST climate data
records that are used to provide the GCOS SST Essential Climate Variable (ECV)
[2], [3], [4] are essential to monitoring and
understanding climate variability, climate-ecosystem interactions such as coral reef health and
sustainable fisheries management, and critical issues like sea level rise and
changing sea ice patterns.
In 1998, SST data production was considered a mature component of the observing
system with demonstrated capability and data products. However, SST product
availability was limited to a few data sets that were large, scientific in
format and difficult to exchange in a near real time manner. Product accuracy
was considered insufficient for the emerging NWP and NOP systems.
Uncertainty estimates for SST products were unavailable with SST products
complicating their application by the NWP and NOP data assimilation community.
At the same time the number of applications requiring an accurate high
resolution SST data stream was growing.
Considering these issues, the Global Ocean Data Assimilation Experiment (GODAE)
[[5]] defined the minimum data specification required for use in operational
ocean models, stating that SST observations with global coverage, a spatial
resolution of 10 km and an accuracy of <0.4 K need to be updated every six
hours [[5]].
Despite the network of SST observations from ships and buoys, the only way to
achieve these demanding specifications was to make full use of space-based
observations. An integrated and international approach was sought to improve
satellite SST measurements, based on four principles:
Respond to user SST requirements through a consensus approach,
Organize activities according to principles of shared responsibility and
subsidiarity, handling matters with the lowest, smallest, or least centralized
competent group possible,
Develop complementarities between independent measurements from earth
observation satellites and in situ sensors,
Maximize synergy benefits of an integrated SST measurement system and
end-to-end user service.
These foundations enabled the international ocean remote sensing community,
marine meteorologists, Space Agencies, and ocean modellers to combine their
energies to meet the GODAE requirements by establishing the GODAE High
Resolution Sea Surface Temperature Pilot Project (GHRSST-PP).
GHRSST-PP established four main tasks relevant to the development of the SST
observing system:
Improve SST data assembly/delivery,
Test available SST data sources,
Perform inter-comparison of SST products,
Develop applications and data assimilation of SST to demonstrate the
benefit of the improved observing system.
GHRSST-PP successfully demonstrated that the requirements of GODAE could be met
when significant amounts of GHRSST-PP data became available in 2006 and was
instrumental in defining the shape and form of the modern-era SST measurement
system and user service over the last 10 years [1].
At the end of the GODAE period in 2009, the GHRSST-PP evolved into the
Group for High Resolution SST (GHRSST). GHRSST built on the successes of the
pilot project phase and continued a series of international workshops that were
held during 2000-2009. These workshops established a set of user requirements
for all GHRSST activities in five areas:
Scientific development and applications,
Operational agency requirements,
SST product specifications,
Programmatic organization of an international SST service,
Developing scientific techniques to improve products and exploit the observing
system.
These requirements were critical to establishing the GHRSST framework and work plan and
formed an essential part of the GHRSST evolution. By establishing and documenting clear
requirements in a consultative manner at the start of the project and through all stages of its
development, GHRSST was able to develop confidently and purposefully to address the needs
of the international SST user community.
Over the last two decades, GHRSST established and now continues to provide an
internationally distributed suite of user focused services in a sustained
Regional/Global Task Sharing (R/GTS) framework [AD-11] that addresses
international organizational challenges and recognizes the implementing
institutional capacities, capabilities, and funding prospects.
Long term stewardship, user support and help services, and standards-based data
management and interoperability have been developed and are operated within the R/GTS
on a daily basis.
The first GHRSST Level 2P datasets were made available in 2006. Since then the GHRSST R/G
TS framework did not change up to 2019. Datasets produced from the collection of
international 14 Regional Data Assembly Centres (RDACs) were ingested by a Global Data
Assembly Centre (GDAC), such as the US GDAC located at the NASA Jet Propulsion Laboratory,
Physical Oceanography Active Archive Data Center PO.DAAC). These data were made
available for public distribution via a number of access protocols, tools and services, and also
staged for ingestion. Final archiving and further distribution services were performed by the
Long-term Stewardship and Reanalysis Facility (LTSRF) located at the NOAA National Center
for Environmental Information (NCEI). This initial GHRSST R/G TS Framework is presented in
Figure 6-1.
Although this initial paradigm has functioned well, it has deviated from its initial design with
the growing number of producers and datasets. As seen in the dashed box in Figure, a new
GDAC was set-up in Europe, delivering products not available at the US GDAC, while other
producers (e.g. CMEMS, Copernicus/EUMETSAT, and JAXA) are also now delivering products
through their own services without any push to a GDAC. It was recognized by the GHRSST
data management experts, through discussions from 2017 to 2019, and confirmed at the
annual GHRSST science team meetings, that a more defined sharing of data management
resources would be beneficial to the future growth of GHRSST and encourage more
participation by other potential data producers. The specification of the GHRSST data
management paradigm for the next years is the focus of the next sections.
It can be summarised by a more distributed system where no entity, but the GHRSST Project
Office, plays a central role anymore, as shown on Figure 6-2.
In the new R/G TS framework, there are now only two types of entities: data producers (GDP
or GHRSST Data Producers) and distributing centres (DAC or Data Assembly Centre). The two
roles can be combined by a single institution (for example, EUMETSAT which produces and
delivers Sentinel-3 A & B products). The GHRSST Project Office (GHRSST-PO) provides and
maintains on its portal a central catalogue of all GHRSST datasets providing collection
(dataset) level metadata, and federated search and discovery services. Each DAC must
implement a minimum set of services for granule data access, search and discovery,
production/distribution metrics and long-term archiving.
Figure 6-2: Revised architecture proposal. Multiple interfaces are now available to data producers. Each data
node implements interface, distribution, archiving and metadata services for the datasets they are
responsible for. Data and metadata from data producers (GDPs) flow first to a DAC (like PO.DAAC, before as
the US GDAC). There is no more GDAC with the commitment to host all GHRSST datasets, it is now a shared
task between DACs and some datasets can be distributed by several DACs. The GHRSST-PO portal allows the
user to discover and search all GHRSST products and granules without prior knowledge of who is the producer
or distributor.
Each component of the R/GTS is independently managed and operated by different
institutions and agencies. The R/GTS itself is coordinated by the international GHRSST Science
Team, which receives guidance and advice from the GHRSST Advisory Council. A GHRSST
Project Office coordinates the overall framework.
The GHRSST R/GTS was made possible through the establishment of a rigorous GHRSST
Technical Data Specification (GDS), which instructed international satellite data providers on
how to process satellite data streams, defined the format and content of the data and
metadata, and documented the basic approaches to providing uncertainty estimates and
auxiliary data sets. The GHRSST-PP established the first GDS (v1.6) [RD-1], which formed the
basis of all GHRSST data production from 2005 through today. Since 2010 the Version 2 of the
GDS has been used in operations, with minor updates occurring from time to time.
All GHRSST products entering the R/GTS must strictly follow the common GDS when
generating L2P, L3, L4, and GMPE data. As a result, users with common tools to read data
from one RDAC can securely use data from any of the others as well as the GDAC and LTSRF
without a need to re-code. Table 6-1 provides a summary of GDS-2.1 data products and their
basic characteristics.
The remainder of this document provides the detailed specifications for GHRSST L2P, L3, L4,
and GMPE products, their file naming convention, metadata requirements, and all necessary
tables, conventions, and best practices for creating and using GHRSST data.
Geophysical variables derived from Level 1 source data at the same resolution and location as the Level 1 data, typically in a satellite projection with geographic information. These data form the fundamental basis for higher-level GHRSST products and require ancillary data and uncertainty estimates. No adjustments to input SST have been made.
L2 data granules remapped to a space grid without combining any observations from overlapping orbits.
SST measurements combined from a single instrument into a space-time grid.
Multiple passes/scenes of data can be combined. Adjustments may be made to input SST data.
SST measurements combined from multiple instruments into a space-time grid. Multiple passes/scenes of data are combined. Adjustments may be made to input SST data.
Grid specification
Native to SST data format
Defined by data provider
Defined by data provider
Defined by data provider
Defined by data provider
Temporal resolution
Native to SST data stream
Native to data stream
Defined by data provider
Defined by data provider
Defined by data provider
Delivery timescale
As available, Ideally within 3 hours from acquisition at satellite
As available, Ideally within 3 hours from acquisition at satellite
As available, Ideally within 3 hours from acquisition at satellite
As available, Ideally within 3 hours from acquisition at satellite
Analyzed product processing window as defined by data provider.
Target accuracy
Native to data stream
Native to data stream
<0.4 K
<0.4 K
< 0.4 K absolute, 0.1 K relative
Error statistics
Native to data stream if available, sensor specific error statistics otherwise
Native to data stream if available, sensor specific error statistics otherwise
Derived from input data for each output grid point.
Derived from input data for each output grid point.
Analysis error defined by data provider for each output grid point (no input data statistics are retained)
Coverage
Native to data stream
Native to data stream
Defined by data provider
Defined by data provider
Defined by data provider
L3 GHRSST products do not use analysis or interpolation procedures to fill gaps
where no observations are available
Contents
search.html 0000664 0001750 0001750 00000034003 14744715212 013414 0 ustar jfpiolle jfpiolle
Search - The Recommended GHRSST Data Specification (GDS)
SST is a challenging parameter to define precisely as the upper ocean (~10 m) has a complex and variable vertical temperature structure that is related to ocean turbulence and air-sea fluxes of heat, moisture and momentum. A theoretical framework is therefore required to understand the information content and relationships between measurements of SST made by different satellites and in situ instruments, especially if these are to be merged together. The definitions of SST developed by the GHRSST SST Science Team (agreed at the 2nd and 3rd workshops) achieve the closest possible coincidence between what is defined and what can be measured, taking into account current scientific knowledge and understanding of the near-surface thermal structure of the ocean.
The definitions of SST defined by GHRSST are currently being refined by the Science Team. Once approved, the GHRSST SST definitions will be iterated with the Climate and Forecast (CF) metadata convention definitions of SST to ensure they are in agreement.
The figure below presents a schematic diagram that summarises the definition of SST in the upper 10 m of the ocean and provides a framework to understand the differences between complementary SST measurements. It encapsulates the effects of dominant heat transport processes and time scales of variability associated with distinct vertical and volume regimes of the upper ocean water column (horizontal and temporal variability is implicitly assumed).
Fig. 3.1 Overview of SST measurement types used within GHRSST#
CF Definition:
sea_surface_temperature is usually abbreviated as “SST”. It is the temperature of sea water near the surface (including the part under sea-ice, if any), and not the interface temperature, whose standard name is surface_temperature. For the temperature of sea water at a particular depth or layer, a data variable of sea_water_temperature with a vertical coordinate axis should be used.
Additional details
The interface temperature (SSTint) is a theoretical temperature at the precise air-sea interface. It represents the hypothetical temperature of the topmost layer of the ocean water and could be thought of as an even mix of water and air molecules. SSTint is of no practical use because it cannot be measured using current technology. It is important to note that it is the SSTint that interacts with the atmosphere. Within GHRSST, most variables containing SST are named “sea_surface_temperature” to simplify the development of client applications wishing to read these variables. The variable attribute “standard_name” indicates the precise form of the SST, using the following definitions. More detail is given in the Level 2P (Section 9), Level 3 (Section 10), and Level 4 (Section 11) specification.
Sea_surface_skin_temperature (GHRSST : SSTskin):
CF Definition:
The surface called “surface” means the lower boundary of the atmosphere. The sea surface skin temperature is the temperature measured by an infrared radiometer typically operating at wavelengths in the range 3.7 - 12 micrometers. It represents the temperature within the conductive diffusion-dominated sub-layer at a depth of approximately 10 - 20 micrometers below the air-sea interface. Measurements of this quantity are subject to a large potential diurnal cycle including cool skin layer effects (especially at night under clear skies and low wind speed conditions) and warm layer effects in the daytime.
Additional Details:
The sea surface skin temperature (SSTskin) as defined above represents the actual temperature of the water across a very small depth of approximately 20 micrometers. This definition is chosen for consistency with the majority of infrared satellite and ship mounted radiometer measurements.
The surface called “surface” means the lower boundary of the atmosphere. The sea surface subskin temperature is the temperature at the base of the conductive laminar sub-layer of the ocean surface, that is, at a depth of approximately 1 - 1.5 millimetres below the air-sea interface. For practical purposes, this quantity can be well approximated to the measurement of surface temperature by a microwave radiometer operating in the 6 - 11 gigahertz frequency range, but the relationship is neither direct nor invariant to changing physical conditions or to the specific geometry of the microwave measurements. Measurements of this quantity are subject to a large potential diurnal cycle due to thermal stratification of the upper ocean layer in low wind speed high solar irradiance conditions.
Additional Details:
The sea surface subskin temperature (SSTsubskin) represents the temperature at the base of the thermal skin layer. The difference between SSTint and SSTsubskin is related to the net flux of heat through the thermal skin layer. SSTsubskin is the temperature of a layer approximately 1 mm thick at the ocean surface.
Sea_water_temperature (GHRSST : SSTdepth or SSTz):
CF Definition:
The general term, “bulk” sea surface temperature, has the standard name sea_surface_temperature with no associated vertical coordinate axis. The temperature of sea water at a particular depth (other than the foundation level) should be reported using the standard name sea_water_temperature and, wherever possible, supplying a vertical coordinate axis or scalar coordinate variable.
Additional Details:
Sea water temperature (SSTdepth or SSTz, for example SST1.5m) is the terminology adopted by GHRSST to represent in situ measurements near the surface of the ocean that have traditionally been reported simply as SST or “bulk” SST. For example SST6m would refer to an SST measurement made at a depth of 6 m. Without a clear statement of the precise depth at which the SST measurement was made, and the circumstances surrounding the measurement, such a sample lacks the information needed for comparison with, or validation of satellite-derived estimates of SST using other data sources. The terminology has been introduced to encourage the reporting of depth (z) along with the temperature.
All measurements of water temperature beneath the SSTsubskin are obtained from a wide variety of sensors such as drifting buoys having single temperature sensors attached to their hull, moored buoys that sometimes include deep thermistor chains at depths ranging from a few meters to a few thousand meters, thermosalinograph (TSG) systems aboard ships recording at a fixed depth while the vessel is underway, Conductivity Temperature and Depth (CTD) systems providing detailed vertical profiles of the thermohaline structure used during hydrographic surveys and to considerable depths of several thousand meters, and various expendable bathythermograph systems (XBT). In all cases, these temperature observations are distinct from those obtained using remote sensing techniques and measurements at a given depth should be referred to as sea_water_temperature qualified by a depth in meters rather than sea surface temperatures. The situation is complicated further when one considers ocean model outputs for which the SST may be the mean SST over a layer of the ocean several tens of meters thick.
The surface called “surface” means the lower boundary of the atmosphere. The sea surface foundation temperature is the water temperature that is not influenced by a thermally stratified layer of diurnal temperature variability (either by daytime warming or nocturnal cooling). The foundation temperature is named to indicate that it is the temperature from which the growth of the diurnal thermocline develops each day, noting that on some occasions with a deep mixed layer there is no clear foundation temperature in the surface layer. In general, sea surface foundation temperature will be similar to a night-time minimum or pre-dawn value at depths of between approximately 1 and 5 meters. In the absence of any diurnal signal, the foundation temperature is considered equivalent to the quantity with standard name sea_surface_subskin_temperature. The sea surface foundation temperature defines a level in the upper water column that varies in depth, space, and time depending on the local balance between thermal stratification and turbulent energy and is expected to change slowly over the course of a day. If possible, a data variable with the standard name sea_surface_foundation_temperature should be used with a scalar vertical coordinate variable to specify the depth of the foundation level. Sea surface foundation temperature is measured at the base of the diurnal thermocline or as close to the water surface as possible in the absence of thermal stratification. Only in situ contact thermometry is able to measure the sea surface foundation temperature. Analysis procedures must be used to estimate sea surface foundation temperature value from radiometric satellite measurements of the quantities with standard names sea_surface_skin_temperature and sea_surface_subskin_temperature. Sea surface foundation temperature provides a connection with the historical concept of a “bulk” sea surface temperature considered representative of the oceanic mixed layer temperature that is typically represented by any sea temperature measurement within the upper ocean over a depth range of 1 to approximately 20 meters. The general term, “bulk” sea surface temperature, has the standard name sea_surface_temperature with no associated vertical coordinate axis. Sea surface foundation temperature provides a more precise, well-defined quantity than “bulk” sea surface temperature and, consequently, is more representative of the mixed layer temperature. The temperature of sea water at a particular depth (other than the foundation level) should be reported using the standard name sea_water_temperature and, wherever possible, supplying a vertical coordinate axis or scalar coordinate variable.
Additional Details:
Through the definition of the CF standard names, GHRSST is attempting to discourage the use of the term “bulk SST”, replacing it instead with sea_water_temperature (SSTdepth) and a depth coordinate, or sea_surface_foundation_temperature (SSTfnd) and a depth coordinate if possible, if the observation comes from the base of the diurnal thermocline.
Blended SST (GHRSST : SSTblend):
In addition to the CF standard names defined above, GHRSST also uses the term “Blended SST” for ambiguous cases when the depth or type of SST is not well known. This ambiguity in depth may arise in some L4 analysis products that merge multiple types of SST from satellite and in situ observations. Note, however, that many L4 analysis systems do attempt to specifically create a sea surface foundation temperature, SSTfnd.
_sources/ 0000775 0001750 0001750 00000000000 14744715212 013103 5 ustar jfpiolle jfpiolle _sources/overview.md 0000664 0001750 0001750 00000053020 14705500531 015264 0 ustar jfpiolle jfpiolle # Overview of GHRSST and the GDS-{{gds_version}}
**GHRSST** [^footnote0] is an international consortium representing commercial
enterprises, academic institutions, research organizations, and operational
agencies that collaborate to provide accurate, high resolution, and consistently
formatted SST observations and analyses from space-based platforms.
This section briefly provides information on the importance of SST, an
overview and history of GHRSST, and context for understanding the
**GDS-{{gds_version}}**.
## The Importance of SST
Sea Surface Temperature at the ocean-atmosphere interface is a fundamental
variable for understanding, monitoring, and predicting fluxes of heat, momentum,
and gas at a variety of scales that determine complex interactions between
atmosphere and ocean. The ocean stores heat from the sun and redistributes it
from the tropical regions to higher latitudes and to the less dense atmosphere
regulating global weather and climate. Through the hydrological cycle the
coupled system controls terrestrial life by redistributing fresh water over the
land surface. From large ocean gyres and atmospheric circulation cells that fuel
atmospheric depression systems, storms and hurricanes with their attendant wind
waves and storm surges, to local scale phenomena such as the generation of sea
breezes and convection clouds, SST at the ocean-atmosphere interface has a
significant societal impact. Accurate knowledge of global SST distribution and
temporal variation at finer spatial resolution is needed as a key input to
numerical weather prediction (NWP) and numerical ocean prediction (NOP) systems
to constrain the modelled upper-ocean circulation and thermal structure at
daily, seasonal, decadal, and climatic time scales, for the exchange of energy
between the ocean and atmosphere in coupled ocean-atmosphere models, and as
boundary conditions for ocean forecasting models. Such models are widely used
operationally for various applications including maritime safety, military
operations, ecosystem assessments, fisheries support, and tourism.
In addition, well-defined and quantified error estimates of SST are also
required for climate time series that can be analysed to reveal the role of the
ocean in short and long term climate variability. A 30 year record of satellite
SST observations is available now, that grows on a daily basis. SST climate data
records that are used to provide the GCOS SST Essential Climate Variable (ECV)
[^footnote1], [^footnote2], [^footnote3] are essential to monitoring and
understanding climate variability, climate-ecosystem interactions such as coral reef health and
sustainable fisheries management, and critical issues like sea level rise and
changing sea ice patterns.
## GHRSST History
In 1998, SST data production was considered a mature component of the observing
system with demonstrated capability and data products. However, SST product
availability was limited to a few data sets that were large, scientific in
format and difficult to exchange in a near real time manner. Product accuracy
was considered insufficient for the emerging NWP and NOP systems.
Uncertainty estimates for SST products were unavailable with SST products
complicating their application by the NWP and NOP data assimilation community.
At the same time the number of applications requiring an accurate high
resolution SST data stream was growing.
Considering these issues, the Global Ocean Data Assimilation Experiment (GODAE)
[[^footnote4]] defined the minimum data specification required for use in operational
ocean models, stating that SST observations with global coverage, a spatial
resolution of 10 km and an accuracy of <0.4 K need to be updated every six
hours [[^footnote4]].
Despite the network of SST observations from ships and buoys, the only way to
achieve these demanding specifications was to make full use of space-based
observations. An integrated and international approach was sought to improve
satellite SST measurements, based on four principles:
- Respond to user SST requirements through a consensus approach,
- Organize activities according to principles of shared responsibility and
subsidiarity, handling matters with the lowest, smallest, or least centralized
competent group possible,
- Develop complementarities between independent measurements from earth
observation satellites and in situ sensors,
- Maximize synergy benefits of an integrated SST measurement system and
end-to-end user service.
These foundations enabled the international ocean remote sensing community,
marine meteorologists, Space Agencies, and ocean modellers to combine their
energies to meet the GODAE requirements by establishing the GODAE High
Resolution Sea Surface Temperature Pilot Project (GHRSST-PP).
GHRSST-PP established four main tasks relevant to the development of the SST
observing system:
- Improve SST data assembly/delivery,
- Test available SST data sources,
- Perform inter-comparison of SST products,
- Develop applications and data assimilation of SST to demonstrate the
benefit of the improved observing system.
GHRSST-PP successfully demonstrated that the requirements of GODAE could be met
when significant amounts of GHRSST-PP data became available in 2006 and was
instrumental in defining the shape and form of the modern-era SST measurement
system and user service over the last 10 years [^footnote0].
At the end of the GODAE period in 2009, the GHRSST-PP evolved into the
Group for High Resolution SST (GHRSST). GHRSST built on the successes of the
pilot project phase and continued a series of international workshops that were
held during 2000-2009. These workshops established a set of user requirements
for all GHRSST activities in five areas:
- Scientific development and applications,
- Operational agency requirements,
- SST product specifications,
- Programmatic organization of an international SST service,
- Developing scientific techniques to improve products and exploit the observing
system.
These requirements were critical to establishing the GHRSST framework and work plan and
formed an essential part of the GHRSST evolution. By establishing and documenting clear
requirements in a consultative manner at the start of the project and through all stages of its
development, GHRSST was able to develop confidently and purposefully to address the needs
of the international SST user community.
## GHRSST Organization
Over the last two decades, GHRSST established and now continues to provide an
internationally distributed suite of user focused services in a sustained
Regional/Global Task Sharing (R/GTS) framework [AD-11] that addresses
international organizational challenges and recognizes the implementing
institutional capacities, capabilities, and funding prospects.
Long term stewardship, user support and help services, and standards-based data
management and interoperability have been developed and are operated within the R/GTS
on a daily basis.
The first GHRSST Level 2P datasets were made available in 2006. Since then the GHRSST R/G
TS framework did not change up to 2019. Datasets produced from the collection of
international 14 Regional Data Assembly Centres (RDACs) were ingested by a Global Data
Assembly Centre (GDAC), such as the US GDAC located at the NASA Jet Propulsion Laboratory,
Physical Oceanography Active Archive Data Center PO.DAAC). These data were made
available for public distribution via a number of access protocols, tools and services, and also
staged for ingestion. Final archiving and further distribution services were performed by the
Long-term Stewardship and Reanalysis Facility (LTSRF) located at the NOAA National Center
for Environmental Information (NCEI). This initial GHRSST R/G TS Framework is presented in
Figure 6-1.
Although this initial paradigm has functioned well, it has deviated from its initial design with
the growing number of producers and datasets. As seen in the dashed box in Figure, a new
GDAC was set-up in Europe, delivering products not available at the US GDAC, while other
producers (e.g. CMEMS, Copernicus/EUMETSAT, and JAXA) are also now delivering products
through their own services without any push to a GDAC. It was recognized by the GHRSST
data management experts, through discussions from 2017 to 2019, and confirmed at the
annual GHRSST science team meetings, that a more defined sharing of data management
resources would be beneficial to the future growth of GHRSST and encourage more
participation by other potential data producers. The specification of the GHRSST data
management paradigm for the next years is the focus of the next sections.
It can be summarised by a more distributed system where no entity, but the GHRSST Project
Office, plays a central role anymore, as shown on Figure 6-2.
In the new R/G TS framework, there are now only two types of entities: data producers (GDP
or GHRSST Data Producers) and distributing centres (DAC or Data Assembly Centre). The two
roles can be combined by a single institution (for example, EUMETSAT which produces and
delivers Sentinel-3 A & B products). The GHRSST Project Office (GHRSST-PO) provides and
maintains on its portal a central catalogue of all GHRSST datasets providing collection
(dataset) level metadata, and federated search and discovery services. Each DAC must
implement a minimum set of services for granule data access, search and discovery,
production/distribution metrics and long-term archiving.
Figure 6-2: Revised architecture proposal. Multiple interfaces are now available to data producers. Each data
node implements interface, distribution, archiving and metadata services for the datasets they are
responsible for. Data and metadata from data producers (GDPs) flow first to a DAC (like PO.DAAC, before as
the US GDAC). There is no more GDAC with the commitment to host all GHRSST datasets, it is now a shared
task between DACs and some datasets can be distributed by several DACs. The GHRSST-PO portal allows the
user to discover and search all GHRSST products and granules without prior knowledge of who is the producer
or distributor.
Each component of the R/GTS is independently managed and operated by different
institutions and agencies. The R/GTS itself is coordinated by the international GHRSST Science
Team, which receives guidance and advice from the GHRSST Advisory Council. A GHRSST
Project Office coordinates the overall framework.
## Overview of the GDS-2.1
The GHRSST R/GTS was made possible through the establishment of a rigorous GHRSST
Technical Data Specification (GDS), which instructed international satellite data providers on
how to process satellite data streams, defined the format and content of the data and
metadata, and documented the basic approaches to providing uncertainty estimates and
auxiliary data sets. The GHRSST-PP established the first GDS (v1.6) [RD-1], which formed the
basis of all GHRSST data production from 2005 through today. Since 2010 the Version 2 of the
GDS has been used in operations, with minor updates occurring from time to time.
All GHRSST products entering the R/GTS must strictly follow the common GDS when
generating L2P, L3, L4, and GMPE data. As a result, users with common tools to read data
from one RDAC can securely use data from any of the others as well as the GDAC and LTSRF
without a need to re-code. Table 6-1 provides a summary of GDS-2.1 data products and their
basic characteristics.
The remainder of this document provides the detailed specifications for GHRSST L2P, L3, L4,
and GMPE products, their file naming convention, metadata requirements, and all necessary
tables, conventions, and best practices for creating and using GHRSST data.
| SST Product | L2 Pre-Processed {numref}`l2p` | L3 Uncollated [Section 1010] | L3 Collated[Section 10] | L3 Super-collated[Section 10] | Analyzed SST[Section 11] |
|:--------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:------------------------------------------------------------------------------------------------------|:----------------------------------------------------------------------------------------------------|:-------------------------------------------------------------------------------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Acronym | L2P | L3U | L3C | L3S | L4 |
| Description | Geophysical variables derived from Level 1 source data at the same resolution and location as the Level 1 data, typically in a satellite projection with geographic information. These data form the fundamental basis for higher-level GHRSST products and require ancillary data and uncertainty estimates. No adjustments to input SST have been made. | L2 data granules remapped to a space grid without combining any observations from overlapping orbits. | SST measurements combined from a single instrument into a space-time grid. | Multiple passes/scenes of data can be combined. Adjustments may be made to input SST data. | SST measurements combined from multiple instruments into a space-time grid. Multiple passes/scenes of data are combined. Adjustments may be made to input SST data. | Data sets created from the analysis of lower level data that results in gridded, gap-free products. SST data generated from multiple sources of satellite data using optimal interpolation are an example of L4 GHRSST products |
| Grid specification | Native to SST data format | Defined by data provider | Defined by data provider | Defined by data provider | Defined by data provider |
| Temporal resolution | Native to SST data stream | Native to data stream | Defined by data provider | Defined by data provider | Defined by data provider |
| Delivery timescale | As available, Ideally within 3 hours from acquisition at satellite | As available, Ideally within 3 hours from acquisition at satellite | As available, Ideally within 3 hours from acquisition at satellite | As available, Ideally within 3 hours from acquisition at satellite | Analyzed product processing window as defined by data provider. |
| Target accuracy | Native to data stream | Native to data stream | <0.4 K | <0.4 K | < 0.4 K absolute, 0.1 K relative |
| Error statistics | Native to data stream if available, sensor specific error statistics otherwise | Native to data stream if available, sensor specific error statistics otherwise | Derived from input data for each output grid point. | Derived from input data for each output grid point. | Analysis error defined by data provider for each output grid point (no input data statistics are retained) |
| Coverage | Native to data stream | Native to data stream | Defined by data provider | Defined by data provider | Defined by data provider |
L3 GHRSST products do not use analysis or interpolation procedures to fill gaps
where no observations are available
[^footnote0]: Donlon, C. J., I. Robinson, K. S Casey, J. Vazquez-Cuervo, E Armstrong, O. Arino, C.
Gentemann, D. May, P. LeBorgne, J. Piollé, I. Barton, H Beggs, D. J. S. Poulter, C. J.
Merchant, A. Bingham, S. Heinz, A Harris, G. Wick, B. Emery, P. Minnett, R. Evans, D.
Llewellyn-Jones, C. Mutlow, R. Reynolds, H. Kawamura and N. Rayner, 2007. The
Global Ocean Data Assimilation Experiment (GODAE) high Resolution Sea Surface
Temperature Pilot Project (GHRSST-PP). Bull. Am. Meteorol. Soc., Vol. 88, No. 8, pp.
1197-1213, https://doi.org/10.1175/BAMS-88-8-1197
[^footnote1]: Global Climate Observing system, 2004. Implementation plan for the
Global observing system for climate in support of the UNFCCC, GCOS – 92, WMO/TD No. 1219, available
from World Meteorological Organization.
[^footnote2]: The Second Report on the Adequacy of the Global Observing Systems for Climate in
Support of the UNFCCC, GCOS – 82, April 2003 (WMO/TD No. 1143), Available online
at http://www.wmo.int/pages/prog/gcos/index.php
[^footnote3]: Satellite Observation of the Climate System: The Committee on
Earth Observation Satellites (CEOS) Response to the Global Climate Observing
System (GCOS) Implementation Plan, Available online at
http://www.ceos.org/pages/CEOSResponse_1010A.pdf
[^footnote4]: Donlon, C. J., P. Minnett, C. Gentemann, T. J. Nightingale,
I. J. Barton, B. Ward and, J. Murray, 2002. Towards Improved Validation of
Satellite Sea Surface Skin Temperature Measurements for Climate Research,
J. Climate, Vol. 15, No. 4, pp. 353-369.
_sources/naming.md 0000664 0001750 0001750 00000047705 14725077514 014720 0 ustar jfpiolle jfpiolle # GDS Filenames and Supporting Conventions
Striving to achieve a flexible naming convention that maintains consistency across processing levels and better serves user needs, the GDS uses a single form for all GHRSST data files. An overview of the format is presented below in {numref}`overview_filenaming` along with example filenames. Details on each of the filename convention components are provided in {numref}`indicative_date` through {numref}`segregator`.
In addition, a best practice has been established for creating character strings used to describe GHRSST SST products and sources of ancillary data. These strings, and associated numeric codes for the SST products, are used within some GHRSST data files but are not part of the filename convention itself. The best practice is described in {numref}`product_codes`.
(overview_filenaming)=
## Overview of Filename Convention and Example Filenames
The filenaming convention for the GDS {{gds_version}} is shown below:
**`--_GHRSST----v-fv.`**
The variable components within braces (“< >”) are summarized in {numref}`filenaming_components` below and detailed in the following sections. Note that dashes (“-“) **are reserved** to separate elements of the file name and **should not** be used in any GHRSST code or the `` element. Example filenames are given later in this section. While no strict limit to filename length is mandated, RDACs are encouraged to keep the length to less than 240 characters to increase readability and usability.
```{table} Filenaming convention components.
:name: filenaming_components
**Name**|**Definition**|**Description**
-----|-----|-----
``|YYYYMMDD|The identifying date for this data set. See {numref}`indicative_date`.
``|HHMMSS|The identifying time for this data set. The time used is dependent on the of the data set: L2P: start time of granule L3U: start time of granule L3C and L3S: centre time of the collation window L4 and GMPE: nominal time of analysis All times should be given in UTC. See {numref}`indicative_time`.
``|The RDAC where the file was created|The Regional Data Assembly Centre (RDAC) code, listed in the GHRSST reference tables at {{gds_reference_tables}}. See {numref}`rdac`.
``|The data processing level code (L2P, L3U, L3C, L3S, or L4)|The data processing level code, defined in {numref}`processing_levels`.
``|The type of SST data included in the file.|Conforms to the GHRSST definitions for SST, defined in {numref}`sst_type`.
``|A character string identifying the SST product set. The string is used uniquely within an RDAC but may be shared across RDACs.|The unique “name” within an RDAC of the product line. See {numref}`product_codes` for the product string lists, one each for L2P, L3, L4, and GMPE products. See {numref}`product_string`.
``|Optional text to distinguish between files with the same . Dashes are not allowed within this element.|This text is used since the other filename components are sometimes insufficient to uniquely identify a file. For example, in L2P or L3U (un-collated) products this is often the original file name or processing algorithm. Note, underscores should be used, not dashes. For L4 files, this element should begin with the appropriate regional code as defined in Section . This component is optional but must be used in those cases were non-unique filenames would otherwise result.
``|nn.n |Version number of the GDS used to process the file. For example, GDS-2.1 = “02.1”.
``|xx.x|Version number for the file, for example, “01.0”.
``|netCDF data file suffix (nc) or ISO metadata file suffix (xml)|Indicates this is a netCDF file containing data or its corresponding ISO-19115 metadata record in XML.
```
**L2_GHRSST Filename Example**
`20070503132300-NAVO-L2P_GHRSST-SSTblend-AVHRR17_L-SST_s0123_e0135-v02.1-fv01.0.nc`
The above file contains GHRSST L2P blended SST data for 03 May 2007, from AVHRR LAC data collected from the NOAA-17 platform. The granule begins at 13:23:00 hours. It is version 1.0 of the file and was produced by the NAVO RDAC in accordance with the GDS {{gds_version}}. The `` text is "SST_s0123_e0135".
**L3_GHRSST Filename Example**
`20070503110153-REMSS-L3C_GHRSST-SSTsubskin-TMI-tmi_20070503rt-v02.1-fv01.0.nc`
The above file was produced by the REMSS RDAC and contains collated L3 sub-skin SST data from the TMI instrument for 03 May 2007. The collated file has a centre time of at 11:01:53 hours. It is version 1.0 of the file and was produced according to GDS {{gds_version}} specifications. Its `` text is “tmi_20070503rt”.
**L4_GHRSST Filename Example**
`20070503120000-UKMO-L4_GHRSST-SSTfnd-OSTIA-GLOB-v02.1-fv01.0.nc`
The above file contains L4 foundation SST data produced at the UKMO RDAC using the OSTIA system. It is global coverage, contains data for 03 May 2007, was produced to GDS {{gds_version}} specifications and is version 1.0 of the file. The nominal time of the OSTIA analysis is 12:00:00 hours.
(indicative_date)=
## ``
The identifying date for this data set, using the format YYYYMMDD, where YYYY is the four-digit year, MM is the two-digit month from 01 to 12, and DD is the two-digit day of month from 01 to 31. The date used should best represent the observation date for the dataset.
(indicative_time)=
## ``
The identifying time for this data set in UTC, using the format HHMMSS, where HH is the two-digit hour from 00 to 23, MM is the two-digit minute from 00 to 59, and SS is the two-digit second from 00 to 59. The time used is dependent on the `` of the data set:
- L2P: start time of granule
- L3U: start time of granule
- L3C and L3S: centre time of the collation window
- L4 and GMPE: nominal time of analysis
All times should be given in UTC and should be chosen to best represent the observation time for this dataset. Note: RDACs should ensure the applications they use to determine UTC proprerly account for leap seconds.
(rdac)=
## ``
Codes used for GHRSST Regional Data Assembly Centres (RDACs) are available on the GHRSST website (https://www.ghrsst.org/resources/ghrsst-data-specification-gds-tables/). New codes are assigned by the GHRSST Data And Systems Technical Advisory Group (DAS-TAG) and entered into the table upon agreement by the GDAC, LTSRF, and relevant RDACs.
(processing_levels)=
## ``
Satellite data processing level definitions can lead to ambiguous situations, especially regarding the distinction between L3 and L4 products. GHRSST identified the use of analysis procedures to fill gaps where no observations exist to resolve this ambiguity. Within GHRSST filenames, the `` codes are shown below in {numref}`processing_level`. GHRSST currently establishes standards for L2P, L3U, L3C, L3S, and L4 (GHRSST Multi-Product Ensembles known as GMPE are a special kind of L4 product for which GHRSST also provides standards).
```{table} GHRSST Processing Level Conventions and Codes
:name: processing_level
**Level**|** Code**|**Description**
:-----:|:-----:|:-----:
Level 0|L0|Unprocessed instrument and payload data at full resolution. GHRSST does not make recommendations regarding formats or content for data at this processing level.
Level 1A|L1A|Reconstructed unprocessed instrument data at full resolution, time referenced, and annotated with ancillary information, including radiometric and geometric calibration coefficients and geo-referencing parameters, computed and appended, but not applied, to L0 data. GHRSST does not make recommendations regarding formats or content for data at this processing level.
Level 1B|L1B|Level 1A data that have been processed to sensor units. GHRSST does not currently make recommendations regarding formats or content for L1B data.
Level 2 Pre-processed|L2P|Geophysical variables derived from Level 1 source data at the same resolution and location as the Level 1 data, typically in a satellite projection with geographic information. These data form the fundamental basis for higher-level GHRSST products and require ancillary data and uncertainty estimates.
Level 3|L3U L3C L3S|Level 2 variables mapped on a defined grid with reduced requirements for ancillary data. Uncertainty estimates are still mandatory. Three types of L3 products are defined: Un-collated (L3U): L2 data granules remapped to a space grid without combining any observations from overlapping orbits Collated (L3C): observations combined from a single instrument into a space-time grid Super-collated (L3S): observations combined from multiple instruments into a space-time grid. Note that L3 GHRSST products do not use analysis or interpolation procedures to fill gaps where no observations are available.
Level 4|L4|Data sets created from the analysis of lower level data that result in gridded, gap-free products. SST data generated from multiple sources of satellite data using optimal interpolation are an example of L4 GHRSST products. GMPE products are a type of L4 dataset.
```
Note that within GHRSST, all L2P files require a full set of extensive ancillary data such as wind speeds and times of observation that are provided as ‘dynamic flags’ that users can manipulate to filter data according to their own quality criteria. L2P files form the basis of higher-level products and are often the best level products for data assimilation. The requirement for dynamic flags is particularly important in this context. Higher-level L3 products are often intended for general use or created for input to Level 4 analysis systems so the requirement for extensive ancillary data is reduced. Since some GHRSST RDACs only process data natively on grids (especially in the case of geostationary platform observations), the GDS {{gds_version}} L3 specification is flexible enough to allow for the creation of L3 files which meet all the content requirements of a L2P file. In all L2P and L3 cases, bias and standard deviation uncertainty estimates are mandatory.
The distinction between L3 GHRSST and L4 GHRSST data is made primarily on whether or not any gap-filling techniques are employed, not on whether data from multiple instruments is used in the L3 product. If no gap filling procedure (such as optimal interpolation) is used, then the product remains a L3 GHRSST product. GHRSST defines three kinds of L3 files: un-collated (L3U), collated (L3C), and super-collated (L3S). If gap filling is used to fill all observations gaps, then the resulting gap-free data are considered L4 GHRSST data products.
(sst_type)=
## ``
In conjunction with the NetCDF Climate and Forecast (CF) community [AD-9] the GHRSST Science Team agreed on the CF standard names for “SST” shown in the following figure and described in more detail below. The names were first included in CF-1.3, and the current version of the standard name table can be found in [AD-8]. In addition, the GHRSST Science Team agreed to use the CF Naming Convention [AD-3] for variable names that do not already exist as part of the CF Convention. CF definitions are used in the GDS and across GHRSST and are shown schematically in {numref}`sst_definition`. The different kinds of SST are detailed later in this section and the relevant `` codes to be used in the filenames are provided.
The SST codes and CF standard names defined above and used within GHRSST are summarized along with their key characteristics in {numref}`sst_types`.
```{table} GHRSST SST Type code and summary table
:name: sst_types
**GHRSST SST Type**|**CF Standard Name**|**Approximate Depth**|**Typically Observed by…**
-----|-----|-----|-----
SSTint|**sea\_surface\_temperature**|0 meters|Not presently measureable
SSTskin|**sea\_surface\_skin\_temperature**|10 – 20 micrometers|Infrared radiometers operating in a range of wavelengths form 3.7 to 12 micrometers
SSTsubskin|**sea\_surface\_subskin\_temperature**|1 – 1.5 millimetres|Microwave radiometers operating in a range of frequencies from 6-11 gigahertz
SSTdepth|**sea\_water\_temperature**|Specified by vertical coordinate (e.g., SST5m)|In situ observing systems
SSTfnd|**sea\_surface\_foundation\_temperature**|1-5 meters pre-dawn|In situ observing systems
SSTblend|None|Unknown|Blend of satellite and in situ observations
```
(product_string)=
## ``
The product strings are used within the GHRSST filename convention and within
the GHRSST unique data set codes described in {numref}`product_codes`. The
satellite platform and satellite sensor entries are also used in the netCDF
global attributes, `platform` and `instrument` GHRSST product files. See
{numref}`global_attributes` for more information on the required
**global attributes**.
In order to improve the consistency of these product strings across
producers, and avoid maintaining specific GHRSST tables, we recommend to use
the CEOS tables as vocabulary for satellite platform and satellite name:
- CEOS platform table: http://database.eohandbook.com/database/missiontable.aspx
- CEOS sensor table: http://database.eohandbook.com/database/instrumenttable.aspx
```{note}
unfitted characters for file naming (like / or spaces) can be replaced with -.
```
The following code nomenclature is recommended for the single sensor products:
`_(_)`
As an example, a product string for a METOP-A AVHRR product would be : _Metop-A\_AVHRR-3_
(segregator)=
## ``
It is possible for the preceding combination of filename components to result in a non-unique filename for any GHRSST product level. In those situations, the use of the `` must be used to ensure each distinct file has a unique file name. In addition, RDACs are free to use this component to add other information to their file names. Some providers, for example, use the name of the original L1b file. Others enter start and stop times of the file in this component. Note that in the case of GHRSST L4 files the `` element must begin with a code that specifies the approximate region covered by the SST analysis product. There are two primary reasons for this requirement, the first of which is to ensure uniqueness in the file names in the cases where an RDAC is using the same L4 analysis system (for example, “ODYSSEA”) to create products for multiple regions (for example, “GAL” (Galapagos Islands Region) and “MED” (Mediterranean Region)). The second reason is that users need to quickly identify at a glance the approximate domain of the L4 products. Users should note that the geographical coordinates associated with each area code are explicitly intended to be only approximate, and not strict. For example, an RDAC producing a near-global coverage data may choose to only produce data on a grid that extends to 85°S. Such a product would use the “GLOB” code. Users must retrieve the precise latitude and longitude limits directly from the L4 netCDF data files.
(product_codes)=
## GHRSST Unique Text Strings and Numeric Codes
This section describes the best practices that have been developed for creating unique text strings and numeric codes that are needed in various places within some GHRSST files. Note that these strings are not part of the filename convention described above, but, like filenames, they apply to all GHRSST product levels and so are described in this part of the GDS.
### SST Variable Text Strings and Numeric Codes
For each official GHRSST product, a unique numeric code and associated text string is defined. The string is listed in the global attribute id (see Section 8.2) for each netCDF file in the product collection. The unique numerical values and text strings for GHRSST SST datasets are established by agreement between the relevant RDAC, GDAC, and the LSTRF, following the Best Practice defined later in this section. The GHRSST L2P, L3, L4 and GMPE product specifications ({numref}`l2p`, {numref}`l3`, {numref}`l4`, and 12, respectively) also require the providing RDAC to use these text strings directly within the netCDF global attribute **source** to indicate the sources of SST used to create the product. In the event that a non-GHRSST dataset is used as a source, as in the case of an L2P product that uses a Level 1 dataset as its source, it too must have an established text string following the best practice below (to the extent possible).
The associated numeric codes are used in some L3S files, which must describe the SST sources pixel-by-pixel in a variable named **source_of_sst** if more than one SST source is used. If only one source is used, the variable **source_of_sst** is not needed and instead the source is indicated simply by using the text string in the global attribute **source** (see Section 8.2 and Section 10.29) as indicated earlier.
### Ancillary and Optional Variable Text Strings and Numeric Codes
GHRSST L2P, L3, L4 and GMPE product specifications ({numref}`l2p`, {numref}`l3`, {numref}`l4`, and 12, respectively) also require the providing RDAC to indicate text strings and associated numeric codes directly within the netCDF global and variable attributes for the sea surface temperature or ancillary sea ice fraction, aerosol depth indicator, climatologies, surface solar irradiance, wind speed, and when relevant, for optional and experimental variables. These text strings and codes do not need to be unique across different data sets, but must be consistent within a given data set and clearly specified within each netCDF file. In these cases, the variable in question should contain an attribute called **flag_meanings** together with a variable called **flag_values**. The **flag_values** attribute shall contain a comma-separated list of the numeric codes for the sources of data used whose order matches the space-separated text strings in the **flag_meanings** attribute.
### Best Practice for Establishing Character Strings
A best practice has been established for defining the text strings to be used in these GHRSST attributes. While a rigid standard for the text strings is not possible, the following best practice should be applied to the extent possible for GHRSST SST datasets and the ancillary and optional variables:
`----v`
The definitions of the components match the definitions from the file naming convention, found in {numref}`filenaming_components`. The component `` is used to distinguish different versions of the same dataset and should be of the form x.y where x is the major and y is the minor version. For ancillary and optional variables, an attempt should be made to follow these conventions to the extent possible. If there is no appropriate GHRSST RDAC to use in the string, then it is recommended that a commonly used acronym for the centre responsible be used. It is recommended that the `` should be one of ICE, ADI, CLIM, SSI, and WSP, for ancillary sea ice fraction, aerosol depth indicator, climatologies, surface solar irradiance, and wind speed variables, respectively.
Notethat many SST text strings not meeting this best practice were established under the GDS version 1 and are already in use.
These codes are used in the GHRSST Central Catalogue as product identifiers.
_sources/sea_surface_temperature.md 0000664 0001750 0001750 00000025552 14625571675 020346 0 ustar jfpiolle jfpiolle # Sea Surface Temperature
SST is a challenging parameter to define precisely as the upper ocean (~10 m) has a complex and variable vertical temperature structure that is related to ocean turbulence and air-sea fluxes of heat, moisture and momentum. A theoretical framework is therefore required to understand the information content and relationships between measurements of SST made by different satellites and in situ instruments, especially if these are to be merged together. The definitions of SST developed by the GHRSST SST Science Team (agreed at the 2nd and 3rd workshops) achieve the closest possible coincidence between what is defined and what can be measured, taking into account current scientific knowledge and understanding of the near-surface thermal structure of the ocean.
The definitions of SST defined by GHRSST are currently being refined by the Science Team. Once approved, the GHRSST SST definitions will be iterated with the Climate and Forecast (CF) metadata convention definitions of SST to ensure they are in agreement.
The figure below presents a schematic diagram that summarises the definition of SST in the upper 10 m of the ocean and provides a framework to understand the differences between complementary SST measurements. It encapsulates the effects of dominant heat transport processes and time scales of variability associated with distinct vertical and volume regimes of the upper ocean water column (horizontal and temporal variability is implicitly assumed).
```{figure} images/sst-definition.gif
---
name: sst_definition
---
Overview of SST measurement types used within GHRSST
```
CF Definition:
> sea_surface_temperature is usually abbreviated as "SST". It is the temperature of sea water near the surface (including the part under sea-ice, if any), and not the interface temperature, whose standard name is surface_temperature. For the temperature of sea water at a particular depth or layer, a data variable of sea_water_temperature with a vertical coordinate axis should be used.
```{admonition} Additional details
The interface temperature (SSTint) is a theoretical temperature at the precise air-sea interface. It represents the hypothetical temperature of the topmost layer of the ocean water and could be thought of as an even mix of water and air molecules. SSTint is of no practical use because it cannot be measured using current technology. It is important to note that it is the SSTint that interacts with the atmosphere. Within GHRSST, most variables containing SST are named “sea_surface_temperature” to simplify the development of client applications wishing to read these variables. The variable attribute “standard_name” indicates the precise form of the SST, using the following definitions. More detail is given in the Level 2P (Section 9), Level 3 (Section 10), and Level 4 (Section 11) specification.
```
**Sea_surface_skin_temperature (GHRSST : SSTskin):**
CF Definition:
> The surface called "surface" means the lower boundary of the atmosphere. The sea surface skin temperature is the temperature measured by an infrared radiometer typically operating at wavelengths in the range 3.7 - 12 micrometers. It represents the temperature within the conductive diffusion-dominated sub-layer at a depth of approximately 10 - 20 micrometers below the air-sea interface. Measurements of this quantity are subject to a large potential diurnal cycle including cool skin layer effects (especially at night under clear skies and low wind speed conditions) and warm layer effects in the daytime.
```{admonition} Additional Details:
The sea surface skin temperature (SSTskin) as defined above represents the actual temperature of the water across a very small depth of approximately 20 micrometers. This definition is chosen for consistency with the majority of infrared satellite and ship mounted radiometer measurements.
```
**Sea_surface_subskin_temperature (GHRSST : SSTsubskin):**
CF Definition:
> The surface called "surface" means the lower boundary of the atmosphere. The sea surface subskin temperature is the temperature at the base of the conductive laminar sub-layer of the ocean surface, that is, at a depth of approximately 1 - 1.5 millimetres below the air-sea interface. For practical purposes, this quantity can be well approximated to the measurement of surface temperature by a microwave radiometer operating in the 6 - 11 gigahertz frequency range, but the relationship is neither direct nor invariant to changing physical conditions or to the specific geometry of the microwave measurements. Measurements of this quantity are subject to a large potential diurnal cycle due to thermal stratification of the upper ocean layer in low wind speed high solar irradiance conditions.
```{admonition} Additional Details:
The sea surface subskin temperature (SSTsubskin) represents the temperature at the base of the thermal skin layer. The difference between SSTint and SSTsubskin is related to the net flux of heat through the thermal skin layer. SSTsubskin is the temperature of a layer approximately 1 mm thick at the ocean surface.
```
**Sea_water_temperature (GHRSST : SSTdepth or SSTz):**
CF Definition:
> The general term, "bulk" sea surface temperature, has the standard name sea_surface_temperature with no associated vertical coordinate axis. The temperature of sea water at a particular depth (other than the foundation level) should be reported using the standard name sea_water_temperature and, wherever possible, supplying a vertical coordinate axis or scalar coordinate variable.
```{admonition} Additional Details:
Sea water temperature (SSTdepth or SSTz, for example SST1.5m) is the terminology adopted by GHRSST to represent in situ measurements near the surface of the ocean that have traditionally been reported simply as SST or "bulk" SST. For example SST6m would refer to an SST measurement made at a depth of 6 m. Without a clear statement of the precise depth at which the SST measurement was made, and the circumstances surrounding the measurement, such a sample lacks the information needed for comparison with, or validation of satellite-derived estimates of SST using other data sources. The terminology has been introduced to encourage the reporting of depth (z) along with the temperature.
```
All measurements of water temperature beneath the SSTsubskin are obtained from a wide variety of sensors such as drifting buoys having single temperature sensors attached to their hull, moored buoys that sometimes include deep thermistor chains at depths ranging from a few meters to a few thousand meters, thermosalinograph (TSG) systems aboard ships recording at a fixed depth while the vessel is underway, Conductivity Temperature and Depth (CTD) systems providing detailed vertical profiles of the thermohaline structure used during hydrographic surveys and to considerable depths of several thousand meters, and various expendable bathythermograph systems (XBT). In all cases, these temperature observations are distinct from those obtained using remote sensing techniques and measurements at a given depth should be referred to as sea_water_temperature qualified by a depth in meters rather than sea surface temperatures. The situation is complicated further when one considers ocean model outputs for which the SST may be the mean SST over a layer of the ocean several tens of meters thick.
**Sea_surface_foundation_temperature (GHRSST : SSTfnd):**
CF Definition:
> The surface called "surface" means the lower boundary of the atmosphere. The sea surface foundation temperature is the water temperature that is not influenced by a thermally stratified layer of diurnal temperature variability (either by daytime warming or nocturnal cooling). The foundation temperature is named to indicate that it is the temperature from which the growth of the diurnal thermocline develops each day, noting that on some occasions with a deep mixed layer there is no clear foundation temperature in the surface layer. In general, sea surface foundation temperature will be similar to a night-time minimum or pre-dawn value at depths of between approximately 1 and 5 meters. In the absence of any diurnal signal, the foundation temperature is considered equivalent to the quantity with standard name sea_surface_subskin_temperature. The sea surface foundation temperature defines a level in the upper water column that varies in depth, space, and time depending on the local balance between thermal stratification and turbulent energy and is expected to change slowly over the course of a day. If possible, a data variable with the standard name sea_surface_foundation_temperature should be used with a scalar vertical coordinate variable to specify the depth of the foundation level. Sea surface foundation temperature is measured at the base of the diurnal thermocline or as close to the water surface as possible in the absence of thermal stratification. Only in situ contact thermometry is able to measure the sea surface foundation temperature. Analysis procedures must be used to estimate sea surface foundation temperature value from radiometric satellite measurements of the quantities with standard names sea_surface_skin_temperature and sea_surface_subskin_temperature. Sea surface foundation temperature provides a connection with the historical concept of a "bulk" sea surface temperature considered representative of the oceanic mixed layer temperature that is typically represented by any sea temperature measurement within the upper ocean over a depth range of 1 to approximately 20 meters. The general term, "bulk" sea surface temperature, has the standard name sea_surface_temperature with no associated vertical coordinate axis. Sea surface foundation temperature provides a more precise, well-defined quantity than "bulk" sea surface temperature and, consequently, is more representative of the mixed layer temperature. The temperature of sea water at a particular depth (other than the foundation level) should be reported using the standard name sea_water_temperature and, wherever possible, supplying a vertical coordinate axis or scalar coordinate variable.
```{admonition} Additional Details:
Through the definition of the CF standard names, GHRSST is attempting to discourage the use of the term “bulk SST”, replacing it instead with sea_water_temperature (SSTdepth) and a depth coordinate, or sea_surface_foundation_temperature (SSTfnd) and a depth coordinate if possible, if the observation comes from the base of the diurnal thermocline.
```
**Blended SST (GHRSST : SSTblend):**
In addition to the CF standard names defined above, GHRSST also uses the term “Blended SST” for ambiguous cases when the depth or type of SST is not well known. This ambiguity in depth may arise in some L4 analysis products that merge multiple types of SST from satellite and in situ observations. Note, however, that many L4 analysis systems do attempt to specifically create a sea surface foundation temperature, SSTfnd.
_sources/l3.md 0000664 0001750 0001750 00000076762 14744701271 013765 0 ustar jfpiolle jfpiolle ---
jupytext:
formats: md:myst
text_representation:
extension: .md
format_name: myst
---
(l3)=
# Level 3 (L3) Product Specification
## Overview description of the GHRSST L3 data product
GHRSST L3 data have been introduced to provide users with gridded, synthetic,
and potentially adjusted SST products, bringing added value with respect to the
original L2P but still allowing traceability to the original dataset. GHRSST L3
products do not use analysis or interpolation procedure to fill gaps where no
observations are available. The GHRSST L3 products include:
- **Un-collated** data that represent a straightforward remapping of L2P GHRSST
data granules to a space grid without combining any observations from
overlapping orbits or times. Although in principle these data may or may not
be adjusted to a reference sensor, in practice the un-collated L3 will
normally be a remapped L2P dataset. For remapping best practices of L2P on
a grid, see {numref}`l2_remapping_best_practice`.
- **Collated** data that grid observations from a single instrument and a single
platform into space and/or time bins. These data may or may not be adjusted to
a reference sensor. For collating best practices, see
{numref}`collating_best_practice` and for adjustment best practices see
{numref}`adjustment_best_practice`.
- **Super-collated** data that combine observations from a multiple instruments
into a space-time grid. In this case, the adjustment to a common reference is
necessary to avoid heterogeneities in the resulting field. For best practices
concerning the creation of super collated files see
{numref}`supercollating_best_practice`
As a result, the format of a L3 file will be able to cope with the three kinds
of L3 SST presented above. The L3 format will include the following parts:
1. **In case the L3 is un-adjusted**, a mandatory section containing the
original L2P information remapped onto the grid point: the original sea
surface temperature, quality level and SSES information. An optional
section including the remapping condition information may also be
provided. These files are essentially gridded L2P files.
2. **In case the L3 is adjusted to a reference**, the adjusted SST value must
be provided, together with the local bias to the reference, the error
generated by the adjustment processing, and the overall error resulting
from the combination of the SSES and the adjustment processing error.
3. **In case the L3 is super-collated**, the source of SST at each pixel is
mandatory.
**Un-adjusted files**: In the case of **un-collated or collated un-adjusted L3
files** the L3 file is derived from L2P data by a remapping process. The
remapping and collating best practices are given in
{numref}`l2_remapping_best_practice`. Their content is thus identical to that
of the L2P, but complementary, optional information on the remapping conditions
may be provided.
**Adjusted files**: Collated files may or may not be adjusted, but a
super-collated file is necessarily adjusted. The super-collating and adjustment
best practices are described in {numref}`collating_best_practice` and
{numref}`adjustment_best_practice`. The principle governing this format is to
allow traceability to the original L2P, while providing the best-adjusted SST
value. A first section (in blue in {numref}`l3_content`) reproduces the original
L2P SST and SSES information as in the un-adjusted version. The reference used
to adjust the SST must be given in the “reference” attribute of the
`adjusted_sea_surface_temperature` variable. The adjusted SST and some error
information are also mandatory. This information, in yellow in
{numref}`l3_content`, is:
- `adjusted_standard_deviation_error`: the total error resulting from the
combination of the SSES error and the adjustment procedure error,
`standard_deviation_to_reference_sst`.
- `bias_to_reference_sst`: the local value of the estimated difference between
the original SST and the reference SST
- `standard_deviation_to_reference_sst`: an estimate of the error resulting
from the adjustment procedure. If the procedure consists of analysing a field
of differences of original SST and reference SST, the
`standard_deviation_to_reference_sst` will be the error of this analysis.
The GHRSST Science Team determined that 5 mandatory fields will form the core
data content of a GHRSST L3 data file. In addition to global attributes and
geo-location information, GHRSST producers must provide the following within
a L3 file:
- Sea Surface temperature data (SST),
- Time of SST measurement,
- Bias and Standard Deviation error estimates for SST data,
- Data quality.
There are a number of optional fields that may be used at the data provider’s
discretion that will form the core data content of a GHRSST data
file ({numref}`l3_data_records`).
The GHRSST L3 file contents are summarized in {numref}`l3_content` below.
```{table} Summary description of the contents within a GHRSST L3 data product
:name: l3_content
:class: l3-content-css
| netCDF File Contents | Description |
|----------------------|-----------------------------------------------------------------------------------------------------------|
| **Coordinate variables** | Information to permit locating data on grids, as defined in {numref}`coordinate_variables` |
| **L2P Data record variables** | Core and auxiliary variables as defined in {numref}`l2p_records` |
| **L3 Data record variables** | Special Level 3 variables as defined in {numref}`l3_data_records` |
| **Global Attributes** | A collection of required global attributes describing general characteristics of the file, as defined in section {numref}`global_attributes` |
```
## L3 data record format specification
This table provides an overview of the GHRSST L3 product pixel data record that
should be created for each input data. Within GHRSST L3 data files, there are
many variables that are defined identically to their L2P counterparts. In
addition, there are several variables that are unique to L3. Both types are
listed below in {numref}`l3_data_records`. In the following sections, each
variable within the L3 data file that is unique to L3 is described in detail.
```{table} Summary description of GHRSST L2P data records
:name: l3_data_records
:class: l3-variables-css
| Variable Name | Description | Units | Storage type |
|-----------------------|------------------------|--------|-----|
| [sea_surface_temperature](__l2p_sea_surface_temperature) | SST measurement values from input L2 satellite data set. | K (kelvin) | short |
| [sst_dtime](__l2p_sst_dtime) | The deviation in time of SST measurement from reference time | s (second)| short |
| [sses_bias](__l2p_sses_bias) | Sensor Specific Error Statistic (SSES) bias error | K (kelvin)| byte |
| [sses_standard_deviation](__l2p_sses_standard_deviation) | Sensor Specific Error Statistic (SSES) standard deviation uncertainty | K (kelvin)| byte |
| [dt_analysis](__l2p_dt_analysis) | The difference between input SST and a GHRSST L4 SST analysis from the previous 24 hour period | K (kelvin)| byte or short|
| [wind_speed](__l2p_wind_speed) | Closest (in time) 10 m surface wind speed from satellite or analysis | m s-1 | byte |
| [wind_speed_dtime_from_sst](__l2p_wind_speed_dtime_from_sst) | Time difference of `wind_speed` data from input L2 SST measurement specified in hours.| h (hour) | byte |
| [source_of_wind_speed](__l2p_source_of_wind_speed) | Source(s) of `wind_speed` data. Mandatory when multiple sources used. | Code| byte |
| [sea_ice_fraction](__l2p_sea_ice_fraction) | Closest (in time) sea ice fraction from satellite or analysis | 1 | byte |
| [sea_ice_fraction_dtime_from_sst](__l2p_sea_ice_fraction_dtime_from_sst) | Time difference of `sea_ice_fraction` data from input L2 SST measurement specified in hours| h (hour)| byte |
| [source_of_sea_ice_fraction](__l2p_source_of_sea_ice_fraction) | Source(s) of `sea_ice_fraction` data | code | byte |
| [aerosol_dynamic_indicator](__l2p_aerosol_dynamic_indicator) | Atmospheric aerosol indicator | | byte |
| [adi_dtime_from_sst](__l2p_adi_dtime_from_sst) | Time difference between the `aerosol_dynamic_indicator` value and SST measurement | h (hour) | byte |
| [source_of_adi](__l2p_source_of_adi) | Source(s) of atmospheric aerosol indicator data | code | byte |
| [l2p_flags](__l2p_l2p_flags) | Data flag values | mask of bits | short |
| [quality_level](__l2p_quality_level) | Overall indication of L2P data quality | enum | byte |
| [satellite_zenith_angle](__l2p_satellite_zenith_angle) | Calculated satellite zenith angle (measured at the Earth's surface between the satellite and the zenith)| degree | byte |
| [solar_zenith_angle](__l2p_solar_zenith_angle) | Calculated solar zenith angle (the angle between the local zenith and the line of sight to the sun, measured at the Earth's surface)| degree | byte |
| [surface_solar_irradiance](__l2p_surface_solar_irradiance) | Near contemporaneous surface solar irradiance| W m-2| byte |
| [ssi_dtime_from_sst](__l2p_ssi_dtime_from_sst) | Time difference between the `surface_solar_irradiance` value and SST measurement in hours | h (hour)| byte |
| [source_of_ssi](__l2p_source_of_ssi) | Source(s) of `surface_solar_irradiance` data | code | byte |
| [or_latitude](__l3_or_latitude) |Original latitude of the satellite measurement as provided in the L2P| degree_north | short or float|
| [or_longitude](__l3_or_longitude) |Original longitude of the satellite measurement as provided in the L2P |degree_east | short or float|
| [or_number_of_pixels](__l3_or_number_of_pixels) |Number of original pixels from the L2P contributing to the binned (space and/or time) average| 1 (unitless) | short|
| [sum_sst](__l3_sum_sst) |Sum of the pixel values going into the space and/or time bin | K (kelvin) | float|
| [sum_square_sst](__l3_sum_square_sst) | Sum of the pixel value squares going into the space and/or time bin | K2 (kelvin^2) | float|
| [adjusted_sea_surface_temperature](__l3_adjusted_sea_surface_temperature) |SST adjusted to the reference. Mandatory for adjusted type file | K (kelvin) | short|
| [adjusted_standard_deviation_error](__l3_adjusted_standard_deviation_error) |Total error standard deviation estimate derived from SSES and adjustment method. Mandatory for adjusted type file | K (kelvin) |byte|
| [bias_to_reference_sst](__l3_bias_to_reference_sst) |Bias error derived from comparison with the reference. Mandatory for adjusted type file | K (kelvin) | short|
| [standard_deviation_to_reference_sst](__l3_standard_deviation_to_reference_sst) |Error standard deviation resulting from the bias estimation method. Mandatory for adjusted type file | K (kelvin) | byte|
| [source_of_sst](__l3_source_of_sst) |Source of SST data. Mandatory for super-collated type file |code | byte|
| [other fields](__l2p_optional_fields) | Optional/experimental fields defined by data provider | | |
```
(__l3_or_latitude)=
### `or_latitude`
**Optional.**
This variable is the original latitude of the contributing pixel in case of
remapping to the nearest pixel, or the average latitude of the contributing
pixels in case of averaging.
The variable `or_latitude` will be included either as a floating point
variable similarly to the grid latitude and longitude, or as a short variable,
with the format requirements shown in {numref}`l3_or_latitude`, if the required
precision is compatible.
```{table} CDL example description of **or_latitude** variable
:name: l3_or_latitude
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| short or float | `or_latitude` | Original latitude of the satellite measurement | degree_north |
```
```{code-cell}
:tags: [remove-input]
:name: l3_or_latitude
!ncdump -h samples/l3s_full_example.nc | grep $'[ , \t]or_latitude[(,:]'| sed 's/[[:space:]]//'
```
(__l3_or_longitude)=
### `or_longitude`
**Optional.**
This variable is the original longitude of the contributing pixel in case of
remapping to the nearest pixel, or the average longitude of the contributing
pixels in case of averaging.
The variable `or_longitude` shall be included either as a floating point
variable similarly to the grid latitude and longitude, or as a short variable,
with the format requirements shown in {numref}`l3_or_longitude`, if the
required precision is compatible.
```{table} CDL example description of **or_longitude** variable
:name: l3_or_longitude
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| short or float | `or_longitude` | Original longitude of the satellite measurement | degree_east |
```
```{code-cell}
:tags: [remove-input]
:name: l3_or_longitude
!ncdump -h samples/l3s_full_example.nc | grep $'[ , \t]or_longitude[(,:]'| sed 's/[[:space:]]//'
```
(__l3_or_number_of_pixels)=
### `or_number_of_pixels`
**Mandatory.**
This variable is the number of original pixels from the L2P contributing to
the binned (space and/or time) average.
The variable `or_number_of_pixels` shall be included with the format
requirements shown in {numref}`l3_or_number_of_pixels`.
```{table} CDL example description of **or_number_of_pixels** variable
:name: l3_or_number_of_pixels
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| short | `or_number_of_pixels` | Number of pixels from the L2P contributing to the SST value | "1" (unitless) |
```
```{code-cell}
:tags: [remove-input]
:name: l3_or_number_of_pixels
!ncdump -h samples/l3s_full_example.nc | grep $'[ , \t]or_number_of_pixels[(,:]'| sed 's/[[:space:]]//'
```
(__l3_sum_sst)=
### `sum_sst`
**Optional.**
This variable is the sum of the original SST pixel values contributing to the
binned (space and/or time) average.
The variable `sum_sst` shall be included with the format requirements shown in
{numref}`l3_sum_sst`.
```{table} CDL example description of **sum_sst** variable
:name: l3_sum_sst
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| short | `sum_sst` | Sum of the pixel values going into the space and/or time bin | K (kelvin) |
```
```{code-cell}
:tags: [remove-input]
:name: l3_sum_sst
!ncdump -h samples/l3s_full_example.nc | grep $'[ , \t]sum_sst[(,:]'| sed 's/[[:space:]]//'
```
(__l3_sum_square_sst)=
### `sum_square_sst`
**Optional.**
This variable is the sum of the squares of the original SST pixel values
contributing to the binned (space and/or time) average.
The variable `sum_square_sst` shall be included with the format requirements
shown in {numref}`l3_sum_square_sst`.
```{table} CDL example description of **sum_square_sst** variable
:name: l3_sum_square_sst
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| short | `sum_square_sst` | Sum of the pixel value squares going into the space and/or time bin | K2 |
```
```{code-cell}
:tags: [remove-input]
:name: l3_sum_square_sst
!ncdump -h samples/l3s_full_example.nc | grep $'[ , \t]sum_square_sst[(,:]'| sed 's/[[:space:]]//'
```
(__l3_adjusted_sea_surface_temperature)=
### `adjusted_sea_surface_temperature`
**Mandatory for adjusted type files.**
This variable is the SST adjusted to the reference. See the principles of
the adjustment procedure in {numref}`adjustment_best_practice`.
The variable `adjusted_sea_surface_temperature` shall be included with the
format requirements shown in {numref}`l3_adjusted_sea_surface_temperature`.
```{table} CDL example description of **adjusted_sea_surface_temperature** variable
:name: l3_adjusted_sea_surface_temperature
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| short | `adjusted_sea_surface_temperature` | SST values after adjustment to the reference|K (kelvin) |
```
```{code-cell}
:tags: [remove-input]
:name: l3_adjusted_sea_surface_temperature
!ncdump -h samples/l3s_full_example.nc | grep $'[ , \t]adjusted_sea_surface_temperature[(,:]'| sed 's/[[:space:]]//'
```
(__l3_adjusted_standard_deviation_error)=
### `adjusted_standard_deviation_error`
**Mandatory for adjusted type files.**
This variable represents the total error associated with the
`adjusted_sea_surface_temperature` variable. It represents the accumulated
error of the SST production (the `sses_standard_deviation`) and the SST
adjustment (`standard_deviation_to_reference_sst`).
The variable `adjusted_standard_deviation_error` shall be included with the
format requirements shown in {numref}`l3_adjusted_standard_deviation_error`.
```{table} CDL example description of **adjusted_standard_deviation_error** variable
:name: l3_adjusted_standard_deviation_error
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| byte | `adjusted_standard_deviation_error` | Total error standard deviation estimate derived from SSES and adjustment method|K (kelvin) |
```
```{code-cell}
:tags: [remove-input]
:name: l3_adjusted_standard_deviation_error
!ncdump -h samples/l3s_full_example.nc | grep $'[ , \t]adjusted_standard_deviation_error[(,:]'| sed 's/[[:space:]]//'
```
(__l3_bias_to_reference_sst)=
### `bias_to_reference_sst`
**Mandatory for adjusted type files.**
This quantity represents the local value of the adjustment to the reference.
The variable `bias_to_reference_sst` shall be included with the format
requirements shown in {numref}`l3_bias_to_reference_sst`.
```{table} CDL example description of **bias_to_reference_sst** variable
:name: l3_bias_to_reference_sst
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| byte | `bias_to_reference_sst` | Bias error derived from comparison with the reference|K (kelvin) |
```
```{code-cell}
:tags: [remove-input]
:name: l3_bias_to_reference_sst
!ncdump -h samples/l3s_full_example.nc | grep $'[ , \t]bias_to_reference_sst[(,:]'| sed 's/[[:space:]]//'
```
(__l3_standard_deviation_to_reference_sst)=
### `standard_deviation_to_reference_sst`
**Mandatory for adjusted type files.**
This quantity represents the local error standard deviation resulting from the
bias estimation method.
The variable `standard_deviation_to_reference_sst` shall be included with the
format requirements shown in {numref}`l3_standard_deviation_to_reference_sst`.
```{table} CDL example description of **standard_deviation_to_reference_sst** variable
:name: l3_standard_deviation_to_reference_sst
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| short | `standard_deviation_to_reference_sst` | Error standard deviation resulting from the bias estimation method|K (kelvin) |
```
```{code-cell}
:tags: [remove-input]
:name: l3_standard_deviation_to_reference_sst
!ncdump -h samples/l3s_full_example.nc | grep $'[ , \t]standard_deviation_to_reference_sst[(,:]'| sed 's/[[:space:]]//'
```
(__l3_source_of_sst)=
### `source_of_sst`
**Mandatory and only applicable to super-collated (L3S) type files.**
This variable represents the source(s) of SST data when merging the
values from different input datasets.
When only one source is used, this variable is not needed and the appropriate
text string indicating the source is placed in the `source` attribute of the
`sea_surface_temperature` variable.
For multiple sources, the GDS-{{gds_version}} requires the following:
- The variable in question should contain an attribute called `flag_meanings`
and another one called `flag_values`. The `flag_values` attribute shall
contain a comma-separated list of the numeric codes for the sources of data
used whose order matches the comma-separated text strings in the
`flag_meanings` attribute.
- These text strings and numeric codes do not need to be unique across different
data sets or even ancillary variables, but must be consistent within a given
variable and clearly specified within each netCDF variable and its attributes.
A best practice for naming the text strings in provided in
{numref}`product_codes`.
In a super-collated file (L3S), the variable `source_of_sst` shall be included
with the format requirements shown in {numref}`l3_source_of_sst`.
```{table} CDL example description of **source_of_sst** variable
:name: l3_source_of_sst
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| byte | `source_of_sst` | Origin of the SST at pixel level| code |
```
```{code-cell}
:tags: [remove-input]
:name: l3_source_of_sst
!ncdump -h samples/l3s_full_example.nc | grep $'[ , \t]source_of_sst[(,:]'| sed 's/[[:space:]]//'
```
## Sample GHRSST L3 file (CDL header)
A complete CDL description of a L3S dataset is given below.
```{code-cell}
:tags: [remove-input]
:name: l3s_dump
!ncdump -h samples/20240101000000-IFR-L3S_GHRSST-SSTfnd-ODYSSEA-GLOB_010-v02.2-fv01.0.nc
```
## Best Practices
(l2_remapping_best_practice)=
### Remapping Level 2 Data to a Fixed Grid
The remapping procedure consists in remapping the original L2P in swath
projection onto a fixed grid. This remapping should preserve the traceability of
the SST at pixel level and keep the best quality data.
If the original and final grid resolutions are similar, the nearest pixel
remapping should be adopted. To do so, either a “source to target” or a “target
to source” approach may be used. The latter, target to source, which consists in
scanning the target grid points to find the nearest pixel in the source, is
recommended since it avoids creating holes in the remapped field.
If the original grid resolution is finer than the output grid,
{numref}`regridding1` an averaging procedure can be adopted. For these cases the
best practice is to average the values of all pixels which overlap the product
cell entirely and which have a L2P confidence record `quality_level` value equal
to the highest encountered within the cell, to produce a single value.
```{figure} images/regridding1.png
---
name: regridding1
---
To illustrate the approach when the L3 product output grid is over-sampled by
the L2P input data. All pixels labeled p in the input data are possible
contributors to the value for new cell A.
```
The following practices are recommended by the GDS:
1. In the case of a smaller L2P input pixel than the grid cell size, L3 data
product cell values are derived from an average of the L2P pixel which
completely overlap the product cell and which have a L2P quality record
`quality_level` value equal to the highest encountered within the cell,
to produce a single value.
2. For input pixels that straddle the boundary between output grid cells, a
weighting function may be applied to the input values according to the
degree of coverage of the output grid cell and according to the SSES.
3. Only the best quality original data within a grid cell should be averaged
to produce the resulting SST value, to preserve the homogeneity of the
SST quality (recommendation 1 above). In the case of averaging, the
number of contributors can be recorded as well as the sum of the SST
values and the sum of the square values of the SST. The SSES and
ancillary data (if needed, for instance if there may be more that one
SSES couple of values (bias and standard deviation) by quality level)
must be averaged accordingly: the `sses_bias` values are averaged
similarly as the SST values, the new `sses_standard_deviation` value is
the square root of the averaged squared values of the contributing
`sses_standard_deviations`. The averaging should account for the nature
of the original `l2P_flags`.
4. In the case of a larger pixel than the L3 grid cell size, 2 approaches
can be adopted:
- The value of the L2P pixel is allocated to the grid cell the closest to
the pixel centre.
- The output grid cell takes the value of the L2P pixel in which its
centre lies. In this case the original latitudes and longitudes of the
pixel must be recorded, to be able to detect where the original L2P
pixel value has been duplicated.
If the original grid resolution is larger than the output grid (e.g.,
microwave instruments), as illustrated in {numref}`regridding2`, the following
practices are recommended by the GDS:
```{figure} images/regridding2.png
---
name: regridding2
---
To illustrate the approach when the L3 output grid is under-sampled by the
L2P data. Either Grid cell C is assigned the value of pixel p, Or grid cell
A is assigned the value of pixel p and grid cell B is assigned the weighted
average of p and q provided they both have quality flags with the same rating.
```
(collating_best_practice)=
### Collating Data from the Same Sensor and Platform
The collating procedure consists of gathering over a unique grid several orbits
or slots (in the case of a geostationary satellite) of the same sensor on the
same platform. This process is often known as “binning” the data. The collating
procedure merges data with different times of observation.
1) For situations in which the collation is to be done for data collected within
the same day, two cases are met in practice: collation of consecutive orbits
in the case of data collected from polar orbiting sensors, or the merging of
consecutive slots in the case of geostationary satellites. In both cases
there may be multiple candidates for a grid cell.
a. To collate observations from overlapping orbits of the polar orbiting
sensors, the selection procedure should prioritize data first by using the
highest available quality data. If multiple observations share the same
highest quality, one of two approaches should be taken: either the
observation with the minimum satellite zenith angle should be selected, or
the observations should be averaged. If the minimum satellite zenith angle
approach is taken, the corresponding `sses_bias` and
`sses_standard_deviation` should be selected as well. If the averaging
approach is followed, the `sses_bias` and `sses_standard_deviation` should be
averaged similarly (note that the new `sses_standard_deviation` value is the
square root of the averaged squared values of the contributing
sses_standard_deviation values). Also in the case of averaging, it is good
practice to record the number of observations being averaged, the sum of the
SST values, and the sum of the squared SST values. These values can be stored
in the `or_number_pixels`, `sum_sst`, and `sum_square_sst` variables
listed in Sections and 8 and 9.
b. In the case of geostationary data, the selection procedure must prioritize
data showing the best quality level, and if equal, data closest to the
representative time (central time) of the L3 time window. In the case of
geostationary satellites, remapping is not a preliminary step to the
collating procedure.
2) If averaging over multiple days, only the best quality original data within a
grid cell should be averaged to produce the resulting SST value, to preserve
the homogeneity of the SST quality. The number of contributors can be
recorded (`or_number_pixels`) as well as the sum of the SST values (
`sum_sst`) and the sum of the square values of the SST (`sum_square_sst`).
The SSES values should be averaged accordingly: the `sses_bias` values are
averaged in the same manner as the SST values and the new
`sses_standard_deviation` value is the square root of the averaged squared
values of the contributing `sses_standard_deviation` values. The averaging
should preserve the nature of the original `l2P_flags`.
(adjustment_best_practice)=
### SST Adjustments
Most of individual sensors show regional biases resulting in limitations of the
applied algorithms. The objective of the adjustment procedure is to provide a
correction to these regional biases by comparison with a “reference sensor”,
supposedly free from such biases. A variety of sources can be adopted as
references in the adjustment procedure, ranging from AATSR or in situ
measurement to using a median of sensors approach. The adopted reference must be
recorded in the `adjusted_sea_surface_temperature` variable “reference”
attribute.
The adjustment procedure includes the following steps:
1. application of the SSES,
2. determination of the bias adjustment to the reference,
3. evaluation of the error of the adjustment procedure
```{note}
A skin to subskin conversion may be needed. In that case, please refer to
the STVAL recommendations. The type of the SST variables must be recorded in the
standard_names of the `sea_surface_temperature` and
`adjusted_sea_surface_temperature` variables. The bias adjustment value at
pixel and the error of the adjustment procedure must be recorded in the
corresponding variables (mandatory).
```
(supercollating_best_practice)=
### Super-Collating Data from Multiple Sensors and Platforms
The building of a super-collated file takes place by merging adjusted collated
L3 files from various sensors over the same grid and over the same time window.
There is one input candidate file (and hence one candidate observation) per
sensor. There may be multiple candidates for a given grid cell originating from
different sensors. To make the selection from among the candidates, a “decision
tree” or selection hierarchy should be established a priori. This hierarchy
depends on the objective of the super-collation procedure, and may be quite
different for a moderate resolution (10km) super-collated over 24h aiming to
feed a foundation SST analysis and for a high resolution (2km) hourly subskin
SST super-collated aiming to feed a diurnal warming analysis, for example.
Because the hierarchy must be established based on the intended use of the
super-collated dataset that results, it is out of the scope of this document to
define any single hierarchy. However, the adopted hierarchy must be described in
the `comment` attribute of the `adjusted_sea_surface_temperature` variable.
In addition, it is mandatory to provide the source of the SST (`source_of_sst`)
at the grid cell level.
_sources/l2p.md 0000664 0001750 0001750 00000202564 14744701353 014134 0 ustar jfpiolle jfpiolle ---
jupytext:
formats: md:myst
text_representation:
extension: .md
format_name: myst
---
(l2p)=
# Level 2 Pre-processed (L2P) Product Specification
## Overview description of the GHRSST L2P data product
The GHRSST Level-2 Pre-processed (L2P) products are the basic building blocks
from which all other GHRSST SST data products can be derived. L2P data products
should ideally be made available within the GHRSST R/GTS framework to the user
community in real time within 3 hours after the reception of data at the
satellite.
L2P products include SST data as delivered by a data provider in their native
format (swath for polar orbiting satellite), together with a number of
ancillary fields that simplify interpretation and application of the SST data.
The main difference between input L2 SST data file and the output GHRSST L2P
data file is that additional confidence data and sensor specific error estimates
for each pixel value are included and the original SST data files are
reformatted into the L2P specification. No adjustments to the input L2 SST
measurements are allowed but instead, sensor specific error statistics are used
to provide bias error and standard deviation estimates. A user wishing to
correct L2P SST data can apply these estimates to the SST values directly.
Full orbit input data files may be split into ascending and descending files or
smaller granules and a unique L2P output may be generated for each file.
The common format of L2P products allows data users to code with the security
so that as new satellite derived SST data sets are brought on-line, very minimal
code changes are required to make full use of new L2P data. Time previously
spent on coding different i/o routines for each satellite data set can now be
spent applying the data to various applications and societal benefits instead.
The GHRSST Science Team agreed at *the 6th GHRSST Science Team Meeting, Met
Office, Exeter, United Kingdom, May 14th – 20th 2005*, 6 mandatory fields form
the core data content of a GHRSST L2P data file. These fields will be known as
**L2P ‘core’ (L2Pcore)** fields. In addition to global attributes and
geo-location and time information, GHRSST producers must provide the following
L2Pcore fields within an L2P file:
- Sea Surface Temperature data (`sea_surface_temperature`)
- Time differences of SST measurements from a reference time (`sst_dtime`)
- SST Sensor Specific Error Statistic (SSES) measurement bias estimate
(`sses_bias`)
- SSES measurement standard deviation estimate (`sses_standard_deviation`)
- Flags specific to each L2P data set that help users interpret data
(`l2p_flags`)
- A quality level for each measurement (`quality_level`)
In addition there are a number of auxiliary fields (**L2Paux**) that must be
provided before the L2P data product is admitted into the GHRSST R/GTS:
- the difference between satellite SST measurements and a
defined reference climatology of SST (`dt_analysis`)
- An estimate of surface wind speed (`wind_speed`)
- An estimate of sea ice fraction (`sea_ice_fraction`)
- An estimate of atmospheric aerosol (as an aerosol dynamic indicator,
`aerosol_dyanamic_indicator`)
When an L2P file contains all L2Pcore and L2Paux fields together, it will be
called a **full-L2P** file. Only full L2P data files should be registered
into the GHRSST R/G TS central catalogue. These distinctions will assist in the
data management of the GHRSST GDS-{{gds_version}}.
Missing L2Paux fields not provided by a producer may be added by a GHRSST
distributor (DAC), if different from the producer, with prior arrangement. In
this case data required the L2Paux files will be procured, checked for quality
and interpolated or processed according to the GDS-{{gds_version}} specification
by the DAC.
Optional experimental fields may be used by producers to provide additional
information at their discretion. It may be necessary to use an additional
netCDF coordinate variable when including experimental fields.
GDS-{{gds_version}} L2P data products are configured as shown in the table
{numref}`l2p_content_summary`, which can be used to locate appropriate
information in this document.
```{table} Summary description of the contents of a GHRSST L2P data product
:name: l2p_content_summary
| netCDF File Contents | Description |
|----------------------|-----------------------------------------------------------------------------------------------------------|
| **Coordinate variables** | Information to permit locating data on non-orthogonal grids, as defined in {numref}`coordinate_variables` |
| **Data record variables** | Core and auxiliary variables as defined in {numref}`l2p_records` |
| **Global Attributes** | A collection of required global attributes describing general characteristics of the file, as defined in section {numref}`global_attributes` |
```
(l2p_records)=
## L2P data record format specification
The {numref}`l2p_variables` provides an overview of the GHRSST L2P
product pixel data record that should be created for each input L2 SST
measurement contained within a L2P file. In the following sections, each
variable within the L2P data file is described in detail.
```{table} Summary description of GHRSST L2P data records
:name: l2p_variables
:class: l2p-variables-css
| Variable Name | Description | Units | Storage type |
|-----------------------|------------------------|--------|-----|
| [sea_surface_temperature](__l2p_sea_surface_temperature) | SST measurement values from input L2 satellite data set. | K (kelvin) | short |
| [sst_dtime](__l2p_sst_dtime) | The deviation in time of SST measurement from reference time | s (second)| short |
| [sses_bias](__l2p_sses_bias) | Sensor Specific Error Statistic (SSES) bias error | K (kelvin)| byte |
| [sses_standard_deviation](__l2p_sses_standard_deviation) | Sensor Specific Error Statistic (SSES) standard deviation uncertainty | K (kelvin)| byte |
| [dt_analysis](__l2p_dt_analysis) | The difference between input SST and a GHRSST L4 SST analysis from the previous 24 hour period | K (kelvin)| byte or short|
| [wind_speed](__l2p_wind_speed) | Closest (in time) 10 m surface wind speed from satellite or analysis | m s-1 | byte |
| [wind_speed_dtime_from_sst](__l2p_wind_speed_dtime_from_sst) | Time difference of `wind_speed` data from input L2 SST measurement specified in hours.| h (hour) | byte |
| [source_of_wind_speed](__l2p_source_of_wind_speed) | Source(s) of `wind_speed` data. Mandatory when multiple sources used. | Code| byte |
| [sea_ice_fraction](__l2p_sea_ice_fraction) | Closest (in time) sea ice fraction from satellite or analysis | 1 | byte |
| [sea_ice_fraction_dtime_from_sst](__l2p_sea_ice_fraction_dtime_from_sst) | Time difference of `sea_ice_fraction` data from input L2 SST measurement specified in hours| h (hour)| byte |
| [source_of_sea_ice_fraction](__l2p_source_of_sea_ice_fraction) | Source(s) of `sea_ice_fraction` data | code | byte |
| [aerosol_dynamic_indicator](__l2p_aerosol_dynamic_indicator) | Atmospheric aerosol indicator | | byte |
| [adi_dtime_from_sst](__l2p_adi_dtime_from_sst) | Time difference between the `aerosol_dynamic_indicator` value and SST measurement | h (hour) | byte |
| [source_of_adi](__l2p_source_of_adi) | Source(s) of `aerosol_dynamic_indicator` data | code | byte |
| [l2p_flags](__l2p_l2p_flags) | Data flag values | mask of bits | short |
| [quality_level](__l2p_quality_level) | Overall indication of L2P data quality | enum | byte |
| [satellite_zenith_angle](__l2p_satellite_zenith_angle) | Calculated satellite zenith angle (measured at the Earth's surface between the satellite and the zenith)| angular_degree | byte or short|
| [solar_zenith_angle](__l2p_solar_zenith_angle) | Calculated solar zenith angle (the angle between the local zenith and the line of sight to the sun, measured at the Earth's surface)| degree | byte |
| [surface_solar_irradiance](__l2p_surface_solar_irradiance) | Near contemporaneous surface solar irradiance| W m-2| byte |
| [ssi_dtime_from_sst](__l2p_ssi_dtime_from_sst) | Time difference between the `surface_solar_irradiance` value and SST measurement in hours | h (hour)| byte |
| [source_of_ssi](__l2p_source_of_ssi) | Source(s) of `surface_solar_irradiance` data | code | byte |
| [other fields](__l2p_optional_fields) | Optional/experimental fields defined by data provider | | |
```
(__l2p_sea_surface_temperature)=
### `sea_surface_temperature`
The variable `sea_surface_temperature` contains the native unmodified L2 SST
of the input data file. L2 SST data are not adjusted in any manner and are
identical to the input data set.
The `sea_surface_temperature` variable shall be included in a L2P product
with the format requirements shown in table
{numref}`l2p_sea_surface_temperature`.
```{table} CDL example description of **sea_surface_temperature** variable
:name: l2p_sea_surface_temperature
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| short | `sea_surface_temperature` | Pixel sea surface temperature value | K (kelvin) |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_sea_surface_temperature
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]sea_surface_temperature[(,:]'| sed 's/[[:space:]]//'
```
The standard_name attribute should be CF-1.7 or later compliant[^footnote1] as
described in table {numref}`sst_standard_names`:
```{table} GHRSST short SST names and CF-1.7 standard names for sea_surface_temperature
:name: sst_standard_names
| GHRSST name | CF-1.7 standard name definitions |
|-------------|---------------------------------------|
| SSTint | `sea_surface_temperature` |
| SSTskin | `sea_surface_skin_temperature` | |
| SSTsubskin | `sea_surface_subskin_temperature` |
| SSTfnd | `sea_surface_foundation_temperature` |
| SSTdepth | `sea_water_temperature` |
```
````{note}
for `SSTdepth`, the attribute `depth` should be used to indicate the depth for
which the SST data are valid e.g.:
```
sea_surface_temperature:standard_name="sea_water_temperature";
sea_surface_temperature:units = "K" ;
sea_surface_temperature:depth = "1 metre" ;
```
````
(__l2p_sst_dtime)=
### `sst_dtime`
The deviation in time of SST measurement from reference time stored in the
netCDF coordinate variable `time` (defined as the start time of granule for L2P).
Minimum resolution should be one second.
The `sst_dtime` variable shall be included in a L2P product with the format
requirements shown in table {numref}`l2p_sst_dtime`.
```{table} CDL example description of **sst\_dtime** variable
:name: l2p_sst_dtime
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| short | `sst_dtime` | Deviation from reference time stored in the coordinate variable, `time` | s (seconds) |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_sst_dtime
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]sst_dtime[(,:]'| sed 's/[[:space:]]//'
```
(__l2p_sses_bias)=
### `sses_bias`
Providing uncertainty estimates for each SST measurement is one of the key user
requirements for GHRSST L2P SST data products. Uncertainty estimates allow users
to select the accuracy level suitable for their application and to make optimum
use of the SST observations (e.g. in data assimilation).
The uncertainties associated with each observation in a data stream are provided
as **Sensor Specific Error Statistic (SSES)**. The SSES are based on
understanding the errors associated with the in-flight performance of an
individual satellite instrument for the retrieval of SST from the measured
radiances. The SSES are provided as a **mean bias error** and its associated
**standard deviation** (in variable `sses_standard_deviation`, see
{numref}`__l2p_sses_standard_deviation`).
There are a variety of methods for determining SSES as they depend on the
specific characteristics of each satellite instrument. Consequently, the L2P
provider can define their own scheme for producing SSES that is tailored to
their specific dataset. However, the SSES scheme must conform to a set of agreed
SSES common principles.
The SSES common principles are maintained on the
[GHRSST website](https://www.ghrsst.org/resources/single-sensor-error-statistic-sses/), and
have been approved by the GHRSST Science Team. The L2P provider must provide
documentation that summarizes the theoretical basis of their SSES scheme, its
implementation, any recommendations for users, and its conformance to the agreed
SSES common principles.
The variable `sses_bias` is used to store SSES bias estimates and shall be
included with the L2P format requirements shown in {numref}`l2p_sses_bias`. Data
producers are reminded to choose appropriate `scale_factor` and `add_offset`
attributes for their data, and to strive for `scale_factor` as close to 0.01 as
possible without “oversaturating” the values.
```{table} CDL example description of **sses_bias** variable
:name: l2p_sses_bias
| **Storage type** | **Name** | **Description** | **Unit** |
|------------------|--------------|----------------------------------|----------|
| byte | sses_bias | SSES bias estimate | K (kelvin) |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_sses_bias
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]sses_bias[(,:]' | sed 's/[[:space:]]//'
```
(__l2p_sses_standard_deviation)=
### `sses_standard_deviation`
**Sensor Specific Error Statistic (SSES) standard deviation** estimates are
generated by the L2P data provider and are specific to a particular satellite
instrument, and must conform to the SSES common principles. See
{numref}`__l2p_sses_bias` for the general description of SSES concept and
associated variables.
The variable `sses_standard_deviation` shall be included with the format
requirements shown in {numref}`l2p_sses_standard_deviation`.
Data producers are reminded to choose appropriate `scale_factors` and
`add_offsets` for their data, and to strive for `scale_factors` as close to
0.01 as possible without “oversaturating” the values.
```{table} CDL example description of **sses_standard_deviation** variable
:name: l2p_sses_standard_deviation
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| byte | sses_standard_deviation | SSES standard deviation. | K (kelvin) |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_sses_standard_deviation
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]sses_standard_deviation[(,:]'| sed 's/[[:space:]]//'
```
(__l2p_dt_analysis)=
### `dt_analysis`
The difference between input SST and a GHRSST L4 SST analysis from the
previous 24 hour period. If storage as byte
does not allow the provider to offer the full precision required for this
field, storage as a short is optionally permitted though byte is preferred.
The L2P variable `dt_analysis` is the temperature difference between an input
L2 SST measurement and a reference SST L4 analysis data set. `dt_analysis` may
be used to indicate potential areas of diurnal variability or gross outliers in
the L2 input SST measurement data set by looking for large deviations from the
previous analysis SST data. Note that `dt_analysis` is an indicator field and
the temperature anomalies may be difficult to interpret in regions of high SST
gradients. Furthermore, interpretation requires a good understanding of the
strengths and weaknesses (e.g. space and time de-correlations) of the chosen
reference L4 analysis system.
`dt_analysis` shall be derived using:
```{math}
:label: eq_dt_analysis
dt\_analysis = SST_{input} – L4_{SST}
```
Where SSTinput is the input satellite L2 measurement and L4
SST is a previous day analysis from a GHRSST L4 System selected by the
data provider. The GHRSST L4 analysis chosen for a given L2P data set variable
should be consistent for all L2P products as far as practically possible. If a
previous analysis SSTfnd data file is not available for use in
{eq}`eq_dt_analysis`, then a mean reference SST or climatology should be
used in its place as defined in {numref}`l2p_dt_analysis_code`.
```{table} Reference SST data sets for use in dt_analysis computation
:name: l2p_dt_analysis_code
| Name | Description | Reference |
|---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------|
| Use code from L4 analysis | The mean SSTfnd computed for a n-1 day period. This product is computed from data provider SSTfnd data products in real time each day | https://www.ghrsst.org/ghrsst-data-services/ghrsst-catalogue/ |
| GMPE_GLOBAL | Daily, 25 km median average SST and sea ice product created using 10 operational SST analysis products from operational centres around the world | https://ghrsst-pp.metoffice.gov.uk/ostia-website/gmpe-monitoring.html |
```
The `dt_analysis` value shall be inserted into the `dt_analysis` field of
the L2P product for the pixel in question as described
{numref}`l2p_dt_analysis`.
```{table} CDL example description of **dt_analysis** variable
:name: l2p_dt_analysis
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| byte or short | dt_analysis | Deviation from previous day (T-1) L4 SSTfnd analysis as defined in the {numref}`l2p_dt_analysis_code`. If no analysis is available, the reference mean SST climatology should be used| K (kelvin) |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_dt_analysis
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]dt_analysis[(,:]'| sed 's/[[:space:]]//'
```
```{note}
The `reference` variable attribute should be used to specify the analysis or
climatology used to compute `dt_analysis` as shown in the example above
following the guidelines in {numref}`l2p_dt_analysis_code`.
```
(__l2p_wind_speed)=
### `wind_speed`
The L2P variable `wind_speed` contains a best estimate of the **10m surface
wind speed, ideally at the time of SST data acquisition** (although this is
rarely possible). Wind speed measurements are required within the GDS as an
indicator of the turbulent state of the air sea interface to interpret the
relationship between satellite and subsurface SST data and assess the severity
of any skin SST temperature deviation, thermal stratification and for use in
diurnal variability adjustment schemes. At low wind speeds, especially in clear
sky conditions, stronger diurnal variability is expected leading to higher
surface layer temperature gradients and the potential for significant
de-coupling of the skin/sub-skin SST from the SST at depth.
Ideally a near contemporaneous wind speed measurement from satellite sensors
should be used but this is impossible for all sensors due to the limited number
of satellite wind speed sensors available. As a surrogate for a measured wind
speed value, analysis product estimates (e.g., from numerical weather prediction
models) may be used as an indication of the surface wind speed. The GDS
specifies the following rules:
> Simultaneous microwave 10m wind speed measurements obtained from the same
> instrument providing the SST measurement shall be used when available to set the
> L2P confidence data variable `wind_speed`.
> In the absence of a simultaneous surface wind speed measurement, an analysis
> product estimated 10m surface wind speed shall be used to set the L2P variable
> `wind_speed`.
The difference in time expressed in hours between the time of SST measurement
and the time of wind speed data should be entered into the L2P confidence data
variable `wind_speed_dtime_from_sst` as described in
{numref}`__l2p_wind_speed_dtime_from_sst`. In the case of an analysis field,
this should be the central (mean) time of an integrated value.
If all of the wind speeds have a single time value, as in the case of an
analysis or model that gives the wind speeds at an instant in time, then the
`wind_speed_dtime_from_sst` variable is not needed and instead a variable level
attribute named `time_offset` is used. The attribute `time_offset` should
store the difference in hours between the `wind_speed` and the reference time,
stored in the variable `time`.
If a single source of data is used in the L2P variable `wind_speed`
(recommended), the L2P variable `source_of_wind_speed` is not required and a
`source` variable attribute of `wind_speed` is sufficient. In that case, it
shall be a single source text string defined by the data provider using the text
string naming best practice given in {numref}`product_codes`.
If multiple sources of data are used, source information should be indicated in
the L2P variable `source_of_wind_speed` as defined by the data provider and as
described in detail in {numref}`__l2p_source_of_wind_speed`, and the
`source` variable attribute of `wind_speed` shall have the value
`source_of_wind_speed`. In addition, the units of all sources used in the file
shall be identical.
The GDS L2P variable `wind_speed` shall be included in L2P products
with the format requirements shown in the {numref}`l2p_wind_speed`.
```{table} CDL example description of **wind_speed** variable
:name: l2p_wind_speed
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| byte | wind_speed | Surface wind speed at 10m height. Resolution should be no less than 1 m s-1 | m s-1 |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_wind_speed
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]wind_speed[(,:]'| sed 's/[[:space:]]//'
```
A single source of wind data is shown in this example which is reported as
`wind_speed:source = "ECMWF_Anaylsis_V2"` the code has been defined by the data
provider using the ancillary data naming rules given in {numref}`product_codes`.
Since all of the wind speeds have the same time, the attribute `time_offset` is
used instead of the variable `wind_speed_dtime_from_sst`.
(__l2p_wind_speed_dtime_from_sst)=
### `wind_speed_dtime_from_sst`
The variable `wind_speed_dtime_from_sst` reports the time difference between
wind speed data and SST measurement in hours. The variable
`wind_speed_dtime_from_sst` shall be included with the format requirements
shown in {numref}`l2p_wind_speed_dtime_from_sst`. In the
case of an analysis field, the central (mean) time of an integrated value should
be used. If all values are the same, this variable is not required.
Instead, use the variable level attribute named `time_offset` with the
variable `wind_speed`.
```{table} CDL example description of **wind_speed_dtime_from_sst** variable
:name: l2p_wind_speed_dtime_from_sst
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| byte | `wind_speed_dtime_from_sst` | This variable reports the time difference of wind speed measurement from SST measurement in hours. | h (hour) |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_wind_speed_dtime_from_sst
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]wind_speed_dtime_from_sst[(,:]'| sed 's/[[:space:]]//'
```
(__l2p_source_of_wind_speed)=
### `source_of_wind_speed`
The source of data used to set the L2P ancillary data variable `wind_speed`
shall be indicated in the L2P variable `source_of_wind_speed` when more than
one source of wind speed data is used in the L2P product.
When only one source is used, this variable is not needed and the appropriate
text string indicating the source is placed in the `source` attribute of the
`wind_speed` variable. If the values in that single source all have the same
time, then a variable attribute `time_offset` set as the difference time in
hours is considered sufficient and the variable `wind_speed_dtime_from_sst`
is not required.
For multiple sources, the GDS-{{gds_version}} requires the following:
- The variable in question should contain an attribute called `flag_meanings`
and another one called `flag_values`. The `flag_values` attribute shall
contain a comma-separated list of the numeric codes for the sources of data
used whose order matches the comma-separated text strings in the
`flag_meanings` attribute.
- These text strings and numeric codes do not need to be unique across different
data sets or even ancillary variables, but must be consistent within a given
variable and clearly specified within each netCDF variable and its attributes.
A best practice for naming the text strings in provided in
{numref}`product_codes`.
- instead of using a `_FillValue` attribute and value for missing data, it is
recommended to set missing pixel values to **0** and add the corresponding
**no_data** meaning in `flag_meanings` attribute.
The variable `source_of_wind_speed` shall conform to the format requirements
shown in the {numref}`l2p_source_of_wind_speed`.
```{table} CDL example description of **source_of_wind_speed** variable
:name: l2p_source_of_wind_speed
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| byte | `source_of_wind_speed` | Sources of `wind_speed` values. | code |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_source_of_wind_speed
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]source_of_wind_speed[(,:]'| sed 's/[[:space:]]//'
```
In this example, `flag_meanings` and `flag_values` contain strings and
numeric codes provided by the data provider according to the best practices
specified in {numref}`l2p_source_of_wind_speed`.
(__l2p_sea_ice_fraction)=
### `sea_ice_fraction`
Some SST data are contaminated in part or wholly by sea ice and the L2P variable
`sea_ice_fraction` is used to quantify the fraction of an area contaminated
with sea ice, ranging from 0 to 1. Some input SST data streams provide a
flag to indicate that the SST measurement is contaminated by sea ice
(e.g., passive microwave radiometers such as AMSR-E).
If an input data set pixel fractional sea ice estimate exists, this should be
used to in the L2P variable `sea_ice_fraction` as described in the
table {numref}`l2p_sea_ice_fraction`.
Best practice suggests that one should approach the issue in the following
way. If an input data set pixel sea ice flag does not exist, and the pixel is
located in or close to a region that may be ice contaminated, a reference sea
ice data set should be used to determine the value of the L2P variable
`sea_ice_fraction`.
If an input data set pixel sea ice flag exists (i.e. indicating sea ice but
not the fractional amount of coverage), this should be used to set the L2P
variable `sea_ice_fraction` to 1.
If the SST input data set includes a sea ice flag in the data stream, bit 3 of
the L2P confidence data variable `l2p_flags` should be set for this pixel as
described in {numref}`__l2p_l2p_flags`.
The difference in time expressed in hours between the time of SST measurement
and the time of sea ice fraction measurement should be entered into the L2P
variable `sea_ice_fraction_dtime_from_sst` as described in
in {numref}`__l2p_sea_ice_fraction_dtime_from_sst`. In the case of an
analysis field, this should be the central (mean) time of an integrated value.
If all ice observations have a single time value, as in the case of an
analysis or model that gives the sea ice values at an instant in time, then the
`sea_ice_fraction_dtime_from_sst` variable is not needed and instead a
variable attribute named `time_offset` is used. The attribute `time_offset`
should store the difference in hours between the `sea_ice_fraction`
and the reference time, stored in the variable `time`.
If a single source of data is used in the L2P variable `sea_ice_fraction`, the
L2P variable `source_of_sea_ice_fraction` is not required and instead the
`source` variable attribute value of `sea_ice_fraction` is sufficient. It shall
be a single source text string defined by the data provider using the text
string naming best practice given in {numref}`product_codes`.
If multiple sources of data are used, source information should be indicated in
the L2P variable `source_of_sea_ice_fraction` as defined by the data provider
and as described in detail in {numref}`__l2p_source_of_sea_ice_fraction`, and
the `source` variable attribute of `sea_ice_fraction` shall have the value
`source_of_sea_ice_fraction`. In addition, the units of all sources used in the
file shall be identical.
The variable attribute `sea_ice_treatment` shall specify how
the sea ice information has been treated by the data provider. Valid options
are: *"Use unmodified (one source)"*, *"use unmodified (multiple ice sources)”*,
or *“modified using onboard sensors"*.
The variable `sea_ice_fraction` will be included with the format requirements
shown in {numref}`l2p_sea_ice_fraction`.
```{table} CDL example description of **sea_ice_fraction** variable
:name: l2p_sea_ice_fraction
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| byte | `sea_ice_fraction` | fractional of sea ice contamination in a given pixel. Ranges from 0 to 1. | 1 (unitless) |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_sea_ice_fraction
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]sea_ice_fraction[(,:]'| sed 's/[[:space:]]//'
```
A single source of sea ice fraction data is shown in this example which is
reported as `sea_ice_fraction:source = "REMSS_AMSRE_V5"` following the
ancillary data naming conventions specified in {numref}`product_codes`. Since
all of ice values have the same time, the attribute `time_offset` is used
instead of the variable `sea_ice_fraction_dtime_from_sst`.
(__l2p_sea_ice_fraction_dtime_from_sst)=
### `sea_ice_fraction_dtime_from_sst`
The variable `sea_ice_fraction_dtime_from_sst` reports the time difference
between sea ice fraction data from SST measurement in hours. This variable is
mandatory when multiple sources of `sea_ice_fraction` are used.
If only one source is used, simply set a variable attribute `time_offset` in
`sea_ice_fraction` variable, as the difference time in hours.
The variable `sea_ice_fraction_dtime_from_sst` shall be included with the format
requirements shown {numref}`l2p_sea_ice_fraction_dtime_from_sst`.
In the case of an analysis field, this should be the central (mean) time of an
integrated value. If all of the values are the same, this variable is not
required. Instead, use the variable level attribute named `time_offset` with
the variable `sea_ice_fraction`. The attribute `time_offset` should store
the difference in hours between the sea ice analysis time and the reference
time, stored in the variable `time`.
```{table} CDL example description of **sea_ice_fraction_dtime_from_sst** variable
:name: l2p_sea_ice_fraction_dtime_from_sst
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| byte | `wind_speed_dtime_from_sst` | This variable reports the time difference between sea ice fraction data from SST measurement in hours. | hour |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_sea_ice_fraction_dtime_from_sst
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]sea_ice_fraction_dtime_from_sst[(,:]'| sed 's/[[:space:]]//'
```
This variable is mandatory when multiple sources for `sea_ice_fraction` are
used. If only one source is used, instead simply set a variable attribute
`sea_ice_fraction:sea_ice_fraction_dtime_from_sst = \`.
(__l2p_source_of_sea_ice_fraction)=
### `source_of_sea_ice_fraction`
The source of data used to set the L2P ancillary data variable
`sea_ice_fraction` shall be indicated in the L2P variable
`source_of_sea_ice_fraction` when more than one source of sea ice fraction data
is used in the L2P product.
When only one source is used, this variable is not needed and the appropriate
text string indicating the source is placed in the source attribute of the
`sea_ice_fraction` variable.
For multiple sources, the GDS-{{gds_version}} requires the following:
- The variable in question should contain an attribute called
`flag_meanings` and another one called `flag_values`. The `flag_values`
attribute shall contain a comma-separated list of the numeric codes for
the sources of data used whose order matches the comma-separated text
strings in the `flag_meanings` attribute.
- These text strings and numeric codes do not need to be unique across
different data sets or even ancillary variables, but must be consistent
within a given variable and clearly specified within each netCDF variable
and its attributes. A best practice for naming the text strings in
provided in {numref}`product_codes`.
- instead of using a `_FillValue` attribute and value for missing data, it is
recommended to set missing pixel values to **0** and add the corresponding
**no_data** meaning in `flag_meanings` attribute.
-
The variable `source_of_sea_ice_fraction` shall conform to the format
requirements shown in {numref}`l2p_source_of_sea_ice_fraction`.
```{table} CDL example description of **source_of_sea_ice_fraction** variable
:name: l2p_source_of_sea_ice_fraction
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| byte | `source_of_sea_ice_fraction` | Source(s) of sea ice values | None |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_source_of_sea_ice_fraction
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]source_of_sea_ice_fraction[(,:]'| sed 's/[[:space:]]//'
```
In this example, `flag_meanings` and `flag_values` contain strings and
numeric codes provided by the data provider according to the best practices
specified in {numref}`product_codes`.
(__l2p_aerosol_dynamic_indicator)=
### `aerosol_dynamic_indicator`
**Mandatory (only for infrared instruments).**
The L2P variable `aerosol_dynamic_indicator` contains an indicator of potential
atmospheric aerosol contamination of infrared satellite SST data.
Infrared-absorbing atmospheric aerosols are a major source of error in
satellite-derived sea surface temperature retrievals. Atmospheric aerosol, such
as Saharan dust outbreaks, volcanic eruptions or from coastal mega cities causes
errors in the atmospheric correction of top of the atmosphere radiances when
retrieving SST from infrared and visible band data sets. A systematic bias in
the tropical North Atlantic Ocean and Arabian Sea due to desert dust outflows in
those regions is apparent.
An aerosol indicator (e.g., derived from satellite measurements or models)
value is assigned to the L2P variable `aerosol_dynamic_indicator` for each
corresponding infrared retrieved SST measurement pixel using data chosen
by the data provider to indicate aerosol contamination. The aerosol
indicator data nearest in space and time to the input pixel SST value
should be used. In the case of microwave SST measurements there is no
requirement to include the `aerosol_dynamic_indicator` L2P variable as
microwave SST retrievals are not affected by atmospheric aerosols. However,
microwave SST data providers may include `aerosol_dynamic_indicator` in an
L2P product.
If a single source of data is used in the L2P variable
`aerosol_dynamic_indicator`, the L2P variable `source_of_adi` is not
required and instead the `source` variable attribute value in
`aerosol_dynamic_indicator` is sufficient. It shall be a single source
text string defined by the data provider using the text string naming best
practice given in {numref}`product_codes`. If all the times have the same
value, then using a variable attribute `time_offset` with variable
`aerosol_dynamic_indicator` is sufficient and the variable
`adi_dtime_from_sst` is not required.
If multiple sources of ADI information are used then, the `source`
variable attribute of `aerosol_dynamic_indicator` variable shall have the
value `source_of_adi`. In addition, the units of all sources used in the
file shall be identical.
The difference in time expressed in hours between the time of SST measurement
and the time of aerosol indicator data should be entered into the L2P variable
`adi_dtime_from_sst` as described in {numref}`__l2p_adi_dtime_from_sst`. In
the case of an analysis field, this should be the central (mean) time of an
integrated value.
If the variable `aerosol_dynamic_indicator` is provided in an L2P product,
it shall be included with the format requirements shown in the
{numref}`l2p_aerosol_dynamic_indicator`.
```{table} CDL example description of **aerosol_dynamic_indicator** variable
:name: l2p_aerosol_dynamic_indicator
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| byte | `aerosol_dynamic_indicator` | Indicator of potential aerosol contamination of infrared satellite data | Provider defined |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_aerosol_dynamic_indicator
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]aerosol_dynamic_indicator[(,:]'| sed 's/[[:space:]]//'
```
A single source of `aerosol_dynamic_indicator` has been used in this example
indicated using the `aerosol_dynamic_indicator:source` and are defined by the
data provider using the ancillary data naming best practice given in
{numref}`product_codes`. Since all of the values have the same time, the
attribute `time_offset` is used instead of the variable
`aerosol_sst_dtime_from_sst` to indicate the offset in hours from the
reference variable `sst_dtime`.
(__l2p_adi_dtime_from_sst)=
### `adi_dtime_from_sst`
The variable adi_dtime_from_sst reports the time difference between aerosol
indicator data from input L2 SST measurement in hours. The variable
`adi_dtime_from_sst` shall be included in L2P products with the format
requirements shown in the {numref}`l2p_adi_dtime_from_sst`. In
the case of an analysis field, this should be the central (mean) time of an
integrated value. If all of the values are the same, this variable is not
required. Instead, use the variable level attribute named `time_offset` with
the variable `aerosol_dynamic_indicator`.
```{table} CDL example description of **adi_dtime_from_sst** variable
:name: l2p_adi_dtime_from_sst
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| byte | `adi_dtime_from_sst` | Time difference of aerosol dynamic indicator data from SST measurement in hours | hour |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_adi_dtime_from_sst
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]sea_ice_fraction_dtime_from_sst[(,:]'| sed 's/[[:space:]]//'
```
(__l2p_source_of_adi)=
### `source_of_adi`
The source of data used to set the L2P ancillary data variable
`aerosol_dynamic_indicator` shall be indicated in the L2P variable
`source_of_adi` when more than one source of SSI data is used in the L2P
product.
When only one source is used, this variable is not needed and the
appropriate text string indicating the source is placed in the sources attribute
of the `aerosol_dynamic_indicator` variable.
For multiple sources, The variable in question should contain an attribute
called `flag_meanings` and another one called `flag_values`. The
`flag_values` attribute shall contain a comma-separated list of the numeric
codes for the sources of data used whose order matches the space-separated text
strings in the `flag_meanings` attribute. These text strings and numeric
codes do not need to be unique across different data sets or even ancillary
variables, but must be consistent within a given variable and clearly
specified within each netCDF variable and its attributes. A best practice
for naming the text strings in provided in {numref}`product_codes`.
instead of using a `_FillValue` attribute and value for missing data, it is
recommended to set missing pixel values to **0** and add the corresponding
**no_data** meaning in `flag_meanings` attribute.
The variable `source_of_adi` shall conform to the with the format requirements
shown in the {numref}`l2p_source_of_adi`.
```{table} CDL example description of **source_of_adi** variable
:name: l2p_source_of_adi
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| byte | `source_of_adi` | Sources of aerosol dynamic indicator values | None |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_source_of_adi
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]source_of_adi[(,:]'| sed 's/[[:space:]]//'
```
In this example, `flag_meanings` and `flag_values` contain strings and numeric
codes provided by the data provider according to the best practices specified
in {numref}`product_codes`.
(__l2p_l2p_flags)=
### `l2p_flags`
**Mandatory.**
The GDS-{{gds_version}} L2P variable `l2p_flags` is used to
- Specify the type of input SST data (either infrared or passive microwave
instrument derived),
- Pass through native flags from the input L2 SST data set and
- Record any additional information considered important for the user of an L2P
data set.
The L2P variable `l2p_flags` holds Boolean (single bit) codes detailed in its
`flag_meanings` and `flag_masks` attributes, and split into two sections:
- The first 6 bits of the L2P variable `l2p_flags` are generic flags that are
common to all L2P data files as defined in the {numref}`l2p_flags_bits`
- Bits 6-15 are defined by the L2P data provider and are specific to each L2
input data stream
```{table} List of bits composing the **l2P_flags** variable
:name: l2p_flags_bits
| Bit | Common flags |
|------|--------------|
| 0 | Set if passive microwave data (not set is assumed to be infrared) |
| 1 | Set if over land (not set is assumed to be ocean) |
| 2 | Set if pixel is over ice |
| 3 | Set if pixel is over a lake (if known) |
| 4 | Set if pixel is over a river (if known) |
| 5 | Reserved for future data |
| 6-15 | Defined by L2 data provider |
```
The `flag_meanings` attribute shall contain a space-separated list of
(string with no space) descriptions for each distinct flag value. For
descriptions containing multiple words, the words shall be linked
by underscores.
The `flag_masks` attribute shall contain a comma-separated list of (numeric)
mask values that isolate the bit or bits that encode each flag value, whose
order matches that of the `flag_meanings` values.
It is recommended not to use `_FillValue` attribute as it is prone to
misinterpretation of the bit mask.
- **Bit 0** of the L2P `l2p_flags` is used to record if an input pixel SST is
derived from an infrared satellite sensor or a passive microwave sensor. If
an input pixel is derived from a passive microwave sensor, bit 0 of the L2P
`l2p_flags` variable should be set to 1. By not setting this flag the pixel is
assumed to be from an infrared sensor.
- **Bit 1** of the L2P `l2p_flags` variable is used to record if an input
pixel is over land or ocean surfaces. If an input pixel is classified as
land covered bit 1 of the L2P `l2p_flags` variable should be set to equal 1.
By not setting this flag the pixel is assumed to be classified as over ocean.
- **Bit 2** of the L2P `l2p_flags` variable is used to record if an input pixel
records ice contamination. If an input pixel is classified as ice
contaminated bit 2 of the L2P `l2p_flags` variable should be set to 1.
- **Bit 3** of the L2P `l2p_flags` variable is used to record if an input pixel
contains any part of a lake, as defined by the GHRSST definition of lakes
(mask). If an input pixel contains any part of a lake, as defined by the
GHRSST definition of lakes (mask), bit 3 of the L2P `l2p_flags` variable
should be set to 1.
- **Bit 4** of the L2P `l2p_flags` variable is optionally used to record if an
input pixel contains any part of a river, as defined by the GHRSST
definition of rivers (mask). If an input pixel contains any part of a
river, as defined by the GHRSST definition of rivers (mask), bit 4 of the
L2P `l2p_flags` variable should be set to 1.
Flags or other information provided with the input L2 SST data should be defined
and assigned to the `l2p_flags` variable using bits 6-15 of the L2P variable
l2p_flags. It is recommended to use single bits for any information, no
combination of multiple bits. If that is not possible, then an additional
experimental byte field should be used instead. Definitions for bits 6-15, if
used, should be given using the variable comment attribute.
The L2P variable `l2p_flags` shall be included in GDS-{{gds_version}} L2P
data files with the format requirements shown in {numref}`l2p_l2p_flags`.
```{table} CDL example description of **source_of_adi** variable
:name: l2p_l2p_flags
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| short | `l2p_flags` | The variable l2p_flags is used to (a) specify the type of input SST data (either infrared or passive microwave instrument derived), (b) pass through native flags from the input L2 SST data set and (c) record any additional information considered important for the user of an L2P data set | None |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_source_of_adi
!ncdump -h samples/l2p_full_example.nc | grep $'[, \t]l2p_flags[(,:]'| sed 's/[[:space:]]//'
```
(__l2p_quality_level)=
### `quality_level`
**Mandatory.**
The L2P variable `quality_level` provides an indicator of the overall quality
of an SST measurement in an L2P file. The GDS requires the following:
The L2P variable `quality_level` shall use an incremental scale from **0 to
5** to provide the user with an indication of the quality of the L2P SST data,
reflecting the CEOS QA4EO (Quality Indicator) guidelines. The value **0**
shall be used to indicate missing data and the value **1** shall be used to
indicate invalid data (e.g. cloud, rain, too close to land - under no conditions
use this data). The remaining values from **2-5** are set at the discretion of
the L2P provider with the proviso that the value **2** shall be used to
indicate the worst quality of usable data and the value **5** shall be used to
indicate the best quality usable data. The L2P provider is required to provide
a description of the quality levels provided as part of the product
documentation.
The L2P variable `quality_level` reflects the quality of SST data from a
single sensor and does not provide an indication of the relative quality
between sensors.
The L2P variable `quality_level` shall be included with the format
requirements shown in the {numref}`l2p_quality_level`.
We recommend not to use the `_FillValue` attribute but rather to use the
value **0** to fill in missing data pixels.
```{table} CDL example description of **quality_level** variable
:name: l2p_quality_level
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| byte | `quality_level` | Overall indicator of SST measurement quality | n/a |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_quality_level
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]quality_level[(,:]'| sed 's/[[:space:]]//'
```
(__l2p_satellite_zenith_angle)=
### `satellite_zenith_angle`
**Optional.**
Sea surface temperature retrievals from satellite instruments degrade as the
sensor zenith angle increases. Measurements made with high viewing angles
relative to nadir appear to be considerably colder than they are in reality. The
L2P variable `satellite_zenith_angle` contains the calculated satellite zenith
angle (measured at the Earth's surface between the satellite and the zenith) for
the input L2 SST based on the satellite geometry at the time of SST data
acquisition.
The GDS L2P variable `satellite_zenith_angle` is an optional field that may be
provided by a data provider. The satellite zenith angle for each input pixel
measurement should be recorded in the L2P variable `satellite_zenith_angle`
having a range of 0° to +90°.
If the L2P variable `satellite_zenith_angle` is included in a L2P data product
it shall conform to the format requirements shown in
{numref}`l2p_satellite_zenith_angle`.
```{table} CDL example description of **satellite_zenith_angle** variable
:name: l2p_satellite_zenith_angle
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| byte or short | `satellite_zenith_angle` | Calculated satellite zenith angle (measured at the Earth's surface between the satellite and the local zenith) for the input L2 SST based on the satellite geometry at the time of SST data acquisition. Ranges from 0 to 90 degrees.| angular_degree |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_satellite_zenith_angle
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]satellite_zenith_angle[(,:]'| sed 's/[[:space:]]//'
```
(__l2p_solar_zenith_angle)=
### `solar_zenith_angle`
**Optional.**
The L2P variable `solar_zenith_angle` contains the calculated solar zenith
angle (the angle between the local zenith and the line of sight to the sun,
measured at the Earth's surface) for the input L2 SST based on the satellite
geometry at the time of SST data acquisition. Solar zenith angle is a function
of time, day number and latitude.
The GDS L2P variable `solar_zenith_angle` is an optional field that may be
provided by a data provider. The solar zenith angle for each input pixel
measurement should be recorded in the L2P variable `solar_zenith_angle` having
a range of 0° to 180°. If the L2P variable `solar_zenith_angle` is included in
a L2P data product it shall conform to the format requirements shown in
{numref}`l2p_solar_zenith_angle`.
```{table} CDL example description of **solar_zenith_angle** variable
:name: l2p_solar_zenith_angle
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| byte or short | `solar_zenith_angle` | Calculated solar zenith angle (measured at the Earth's surface between the sun and the local zenith) for the input SST based on the solar geometry at the time of SST data acquisition. Ranges from 0 to 180 degrees.| angular_degree |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_solar_zenith_angle
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]solar_zenith_angle[(,:]'| sed 's/[[:space:]]//'
```
(__l2p_surface_solar_irradiance)=
### `surface_solar_irradiance`
**Optional.**
Surface Solar Irradiance (SSI) data were originally required within the GDS 1.6
to assess the magnitude and variability of significant diurnal SST variations,
for use in diurnal variability correction schemes, for use in L4 SST analysis
procedures and to interpret the relationship between satellite and in situ SST
data. In the GDS-{{gds_version}}, it is an optional variable. Ideally a near
contemporaneous SSI measurement from satellite sensors should be used but this
is impossible for all areas due to the limited number of geostationary satellite
sensors available. As a surrogate for a measured SSI value, analysis estimates
may be used.
Surface solar Irradiance (SSI) data may be assigned to each L2P SST measurement
pixel using the variable `surface_solar_irradiance`.
An integrated down-welling SSI measurement (e.g., derived from satellite
measurements) should be assigned to each SST pixel value using the
`surface_solar_irradiance` L2P variable. The SSI measurement nearest in space
and time before the input pixel SST value should be used. If no SSI measurement
is available, an integrated SSI value derived from an analysis system nearest in
space and time to the SST measurement should be used to set the value of
`surface_solar_irradiance`.
The difference in time expressed in hours between the time of SST measurement
and the time of surface solar irradiance data should be entered into the L2P
confidence data variable `ssi_dtime_from_sst`. In the case of an analysis
field, this should be the central (mean) time of an integrated value. If all of
the values have the same time, the attribute `time_offset` is used instead of
the variable `ssi_dtime_fraction_dtime_from_sst`. The attribute `time_offset`
should store the difference in hours between the `surface_solar_irradiance`
and the reference time, stored in the variable `time`.
If a single source of data is used in the L2P variable
`surface_solar_irradiance`, the L2P variable `source_of_ssi` is not required
and instead the `surface_solar_irradiance:source` attribute value is sufficient.
It shall be a single source text string defined by the data provider using the
text string naming best practice given in {numref}`product_codes`.
If multiple sources of data are used, source information should be indicated in
the L2P variable `source_of_ssi` as defined by the data provider and as
described in detail in {numref}`l2p_surface_solar_irradiance`. Then,
the `surface_solar_irradiance:source` attribute shall have the value
`source_of_ssi`.
The L2P variable `surface_solar_irradiance` may be included by a data provider
with the format requirements shown in {numref}`l2p_surface_solar_irradiance`.
```{table} CDL example description of **surface_solar_irradiance** variable
:name: l2p_surface_solar_irradiance
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| byte | `surface_solar_irradiance` | Near contemporaneous integrated Surface Solar Irradiance (SSI) data. | $W m^{-2}$ |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_surface_solar_irradiance
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]surface_solar_irradiance[(,:]'| sed 's/[[:space:]]//'
```
A single source of SSI data is shown in this example which is reported as
`surface_solar_irradiance:source = "SSI-MSG_SEVIRI-V1"` The text string has been
defined by the data provider using the text string naming best practice given
in {numref}`product_codes`. Since all of the SSI values have the same time, the
attribute `time_offset` is used instead of the variable `ssi_dtime_from_sst`.
(__l2p_ssi_dtime_from_sst)=
### `ssi_dtime_from_sst`
**Optional (Mandatory only if multiple observation time for
`surface_solar_irradiance` are provided).**
The variable `ssi_dtime_from_sst` reports the time difference between SSI data
from SST measurement in hours. The variable `ssi_dtime_from_sst` shall be
included with the format requirements shown in {numref}`l2p_ssi_dtime_from_sst`.
In the case of an analysis field, the central (mean) time of an integrated value
should be used.
If all of the values are the same, this variable is not required. Instead, use
the variable level attribute named `time_offset` with the variable
`surface_solar_irradiance`.
```{table} CDL example description of **ssi_dtime_from_sst** variable
:name: l2p_ssi_dtime_from_sst
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| byte | `ssi_dtime_from_sst` | This variable reports the time difference between SSI data from SST measurement in hours | hour |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_ssi_dtime_from_sst
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]ssi_dtime_from_sst[(,:]'| sed 's/[[:space:]]//'
```
(__l2p_source_of_ssi)=
### `source_of_ssi`
**Optional (Mandatory only if multiple sources for `surface_solar_irradiance`
are provided).**
The source of data used to set the L2P ancillary data variable
`surface_solar_irradiance` shall be indicated in the L2P variable `source_of_ssi`
when more than one source of SSI data is used in the L2P product. When only one
source is used, this variable is not needed and the appropriate text string
indicating the source is placed in the `source` attribute of the
`surface_solar_irradiance` variable.
For multiple sources, the variable `source_of_ssi` should contain an attribute
called `flag_meanings` and another one called `flag_values`. The `flag_values`
attribute shall contain a comma-separated list of the numeric codes for the
sources of data used whose order matches the space-separated text strings in
the `flag_meanings` attribute.
These text strings and numeric codes do not need to be unique across different
data sets or even ancillary variables, but must be consistent within a given
variable and clearly specified within each netCDF variable and its attributes. A
best practice for naming the text strings in provided in
{numref}`product_codes`.
instead of using a `_FillValue` attribute and value for missing data, it is
recommended to set missing pixel values to **0** and add the corresponding
**no_data** meaning in `flag_meanings` attribute.
The variable `source_of_ssi` shall conform to the format requirements shown
in the {numref}`l2p_source_of_ssi`.
```{table} CDL example description of **source_of_ssi** variable
:name: l2p_source_of_ssi
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| byte | `source_of_ssi` | Sources of surface solar irradiance values | code |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_source_of_ssi
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]source_of_ssi[(,:]'| sed 's/[[:space:]]//'
```
In this example, `flag_meanings` and `flag_values` contain code data provided
by the data provider according to the best practices specified
in {numref}`product_codes`. An example of these codes is given in the
{numref}`l2p_source_of_ssi_codes`.
```{table} Example text string and numeric codes used to identify the sources of data in surface_solar_irradiance:sources and source_of_ssi
:name: l2p_source_of_ssi_codes
| Numeric Code | Text String | Sources of surface solar irradiance Description |
|----------------|----------------------|--------------------------------------------------|
| 0 |no_data |No surface solar irradiance set|
| 1 | SSI-MSG_SEVIRI-V1 |SSI from Meteosat Second Generation SEVIRI instrument (EUMETSAT OSI-SAF|
| 2 | SSI-NOAA-GOES_E-V1 |GOES_E SSI data from NOAA |
| 3 | SSI-NOAA-GOES_W-V1 |GOES_W SSI data from NOAA|
| 4 | SSI-ECMWF-V1 |SSI data from European Centre for Medium Range Weather Forecasting|
| 5 | SSI-NCEP-V1 |SSI data from NOAA’s National Center for Environmental Prediction|
| 6 | SSI-NAVY-NAAPS-V1|SSI data from the US Navy Atmospheric aerosol Prediction system|
| 7 | |Spare to be defined as required|
```
(__l2p_optional_fields)=
### Optional experimental L2P variables included by data provider
Flexibility of L2P product content is provided through the netCDF API, which
allows fully self-describing fields and additional L2P variables may be included
by L2P data providers if they are considered relevant for L2P users. The GDS-{{gds_version}}
also permits the inclusion of R&D variables (e.g. channel radiance data sets,
estimates of Chlorophyll A, fields that facilitate flagging of diurnal
variability, etc.) and 32 bytes per pixel are available in total for
optional/experimental variables in any combination (i.e., variables can be
defined as 32 x byte, 16 x short, 3 x int + 4 x byte, etc). The use of
optional/experimental variables provides a limited amount of flexibility within
the GDS-{{gds_version}} for regional user requirements while maintaining an overall upper
limit on GDS-{{gds_version}} L2P products for data management groups and archive scaling. In
exceptional cases a waiver on the 32 byte ceiling can be requested to extend up
to 64 bytes per pixel.
The GDS-{{gds_version}} issues the following guidance on the inclusion of optional or
experimental variables within L2P data products:
- The sum total of all experimental variables shall not increase L2P record
size by more than **32 bytes** per SST pixel. A **waiver** can be requested
for higher amounts up to 64 bytes.
- CF-1.7 or later compliance should be maintained for all
optional/experimental variables. Where available, a standard_name
attribute should be used.
- It is permitted to use a provider defined coordinate variable associated
with experimental fields but this shall be documented in data provider
documentation.
- Time difference data (dtime values) should be provided for variables when
appropriate.
- The source of data should be indicated: in the single source case as a
variable attribute; as a dedicated variable when mixed data sources are
present.
- Use of experimental variables requires clear documentation by the GHRSST
producer. They shall provide adequate documentation that describes each
variable following the CDL examples provided in this document.
- The variable attribute `comment` shall be used to provide a URL link to a
full description of each data producer defined variable included in the
L2P product.
- Experimental L2P variables if present in an L2P product will be included
with the minimum format requirements shown in {numref}`l2p_experimental`
- Additional global variables may be declared within the L2P product.
```{table} CDL template for data provider defined L2P variables
:name: l2p_experimental
| Storage type definition | Variable name definition | Description | Unit |
|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------|------------------------------|------|
| byte | Provide a variable name in lower case using underscore separators e.g. `my_variable` | Provide a description of `my_variable` stating content purpose and units | Units of `my_variable` |
```
```{code-cell}
:tags: [remove-input]
:name: l2p_experimental
!ncdump -h samples/l2p_full_example.nc | grep $'[ , \t]my_variable[(,:]'| sed 's/[[:space:]]//'
```
## CDL example L2P dataset
The following CDL has been generated for a L2P dataset derived from the VIIRS
sensor on NOAA-20 platform (https://doi.org/10.5067/GHV20-2PO28) . It includes a
number of optional and experimental variables.
**ADD CDL EXAMPLE**
[^footnote1]: netCDF Climate and Forecast (CF) Metadata Conventions version 1.7
or later available from http://cfconventions.org _sources/conventions.md 0000664 0001750 0001750 00000004465 14707171175 016006 0 ustar jfpiolle jfpiolle # Document Conventions
The following sub-sections describe the notation conventions and data storage
types that are used throughout this GDS Technical Specification. Implementation
projects are expected to adhere to the nomenclature and style of the GDS in
their own documentation as much as possible to facilitate international
coordination of documentation describing the data products and services within
the GHRSST R/GTS framework.
## Use of text types
The text styles defined in {numref}`text_styles` are used throughout the GDS.
```{table} Definition of text styles used in the GDS
:name: text_styles
**Text type**|**Meaning**|**Example**
-----|-----|-----
Liberation Mono|Denotes a variable name|`dt_analysis`
Liberation Mono|Denotes a netCDF attribute name|`gds_version_id`
Arial|Denotes regular text.|This is normal text.
```
## Use of colour in tables
The colours defined in {numref}`colour_styles` are used throughout the GDS.
```{table} Storage type definitions used in the GDS
:name: colour_styles
:class: cstyles-css
**Colour**|**Meaning**|**Example**
:-----:|:-----:|:-----:
Grey|Denotes a table column name|`Variable`
Blue|Denotes a mandatory item|`analysed_sst`
Violet|Denotes an item mandatory for only certain situations|`dt_analysis`
Yellow|Denotes an optional item|experimental_field
Green|Denotes grid dimensions|`ni=1024`
Pink|Denotes grid variable dimensions|`float lat(nj, ni)`
```
## Definitions of storage types
Computer storage types referred to in the GDS are defined in {numref}`storage_types` and follow those used in netCDF.
```{table} Storage type definitions used in the GDS
:name: storage_types
**Name**|**Storage Type**
:-----:|:-----:
byte|8 bit signed integer
short|16 bit signed integer
int (or long)|32 bit signed integer
float|32 bit floating point
double|64 bit floating point
string|Character string
```
_sources/intro.md 0000664 0001750 0001750 00000005233 14705223421 014554 0 ustar jfpiolle jfpiolle # The Recommended GHRSST Data Specification (GDS) Version {{gds_version}}
A new generation of integrated Sea Surface Temperature (SST) data products are
being provided by the **[Group for High Resolution Sea Surface Temperature
(GHRSST)](https://doi.org/10.1175/BAMS-88-8-1197)**.
L2 products are provided by a variety of data providers in a common
format. L3 and L4 products combine, in near-real time, various SST data products
from several different satellite sensors and in situ observations and maintain
fine spatial and temporal resolution needed by SST inputs to a variety of ocean
and atmosphere applications in the operational and scientific communities. Other
GHRSST products provide diagnostic data sets and global multi-product ensemble
analysis products. Retrospective reanalysis products are provided in a non-real
time critical offline manner. All GHRSST products have a standard format,
include uncertainty estimates for each measurement, and are served to the
international user community free of charge through a variety of data transport
mechanisms and access points that are collectively referred to as the **GHRSST
Regional/Global Task Sharing (R/GTS) framework**.
The GHRSST Data Specification (GDS) Version {{gds_version}} is a technical
specification of GHRSST products. The GHRSST services are described in a
separate [Architecture Document (GSA)](https://10.5281/zenodo.4700398).
The GDS technical documents are supported by a User Manual. GDS {{gds_version}}
represents a consensus opinion of the GHRSST international community on how to
optimally combine satellite and in situ SST data streams within the R/GTS. The
GDS also provides guidance on how data providers might implement SST processing
chains that contribute to the R/GTS.
This document first provides an overview of GHRSST followed by detailed
technical specifications of the adopted file naming specification and supporting
definitions and conventions used throughout GHRSST and the technical
specifications for all GHRSST Level 2P, Level 3, Level 4.
In addition, the GDS {{gds_version}} Technical Specification provides controlled
code tables and best practices for identifying sources of SST and ancillary data
that are used within GHRSST data files.
The GDS document has been developed for data providers who wish to produce any
level of GHRSST data product and for all users wishing to fully understand
GHRSST product conventions, GHRSST data file contents, GHRSST and Climate
Forecast definitions for SST, and other useful information. For a complete
discussion and access to data products and services, see https://www.ghrsst.org,
which is a central portal for all GHRSST activities.
```{tableofcontents}
```
_sources/l4.md 0000664 0001750 0001750 00000026301 14726356062 013752 0 ustar jfpiolle jfpiolle ---
jupytext:
formats: md:myst
text_representation:
extension: .md
format_name: myst
---
(l4)=
# Level 4 (L4) Product Specification
## Overview description of the GHRSST L4 data product
L4 products are the analyzed SST products, usually derived from GHRSST L2P
products. L4 data products should ideally be made available within the
GHRSST R/GTS framework to the user community within 24 hours.
L4 products include gap-free analyzed SST data together with a number of
ancillary fields that simplify interpretation and application of the SST
data. Data providers are responsible for providing documentation on their
analysis procedure. The common format of L4 products allows data users to
code with the security that as new SST data products are brought on-line,
very minimal code changes are required to make full use of a new L4 product.
Time previously spent on coding different I/O routines for each satellite
data set can be spent working with the data to produce results.
The GHRSST Science Team determined that there will be 4 mandatory fields
that form the core data content of a GHRSST L4 data file. In addition to global
attributes and geo-location information, producers must include the following
within a L4 file:
- Sea Surface temperature data (SST)
- Error estimates for SST data
- Sea ice fraction (only and sea ice covered areas)
- Land/sea/ice flag
In addition, there are a number of optional fields that may be used at the
data provider’s discretion.
The GHRSST L4 file contents are summarized in {numref}`l4_content_summary`
below.
```{table} Summary description of the contents within a GHRSST L4 data product
:name: l4_content_summary
| Description | Required |
|----------------------------------------|-----------|
| **Coordinate variables** | Information to permit locating data on grids, as defined in {numref}`coordinate_variables` |
| **Data record variables** | Core and auxiliary variables as defined in {numref}`l4_records` |
| **Global Attributes** | A collection of required global attributes describing general characteristics of the file, as defined in section {numref}`global_attributes` |
```
## L4 data record format specification
L4 analysed data products are derived from an analysis procedure implemented
at regular intervals (daily, six-hourly or other time periods). L4 data
products include SST, error statistics, sea ice fraction, land/sea/ice mask,
and other optional data for each grid-cell. A **6-byte** experimental block
is available for data providers to test new aspects of the file or
information specific to the analysis system that will eventually transition
into a GHRSST standard L4 analysis field once tested.
{numref}`l4_records` describes the format of GDS L4 variables that should be
created for each L4 grid cell. In the following sections, each variable
within the L4 data file is described in detail.
```{table} L4 SST product data records
:name: l4_records
| Variable Name | Description | Units | Storage type |
|-----------------------|------------------------|--------|-----|
| [analysed_sst](__l4_analysed_sst) | SST from analysis system | K (kelvin) | short |
| [analysis_error](__l4_analysis_error) | Error standard deviation estimate | K (kelvin) | short |
| [sea_ice_fraction](__l4_sea_ice_fraction) | Fractional Sea Ice area concentration | 1 (unitless) | byte |
| [sea_ice_fraction_error](__l4_sea_ice_fraction_error) | If the error estimates on the sea ice field are available, it is recommended to provide this information as an experimental field | 1 (unitless) | byte |
| [mask](__l4_mask) | land/ice/lake mask | | byte |
| [other fields](__l4_optional_fields) | Optional/experimental fields defined by data provider | | |
```
(__l4_analysed_sst)=
### `analysed_sst`
The variable `analysed_sst` will be included with the format requirements shown
in {numref}`l4_analysed_sst`.
The data provider is responsible for providing GHRSST with documentation on
how the analysed SST is determined. Note that the RDAC should place the
`_FillValue` value in pixels that fall on land.
```{table} CDL example description of **analysed_sst** variable
:name: l4_analysed_sst
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|--------------|----------------------------------|----------|
| short | `analysed_sst` | SST values from analysis systems | K (kelvin) |
```
```{code-cell}
:tags: [remove-input]
:name: l4_analysed_sst
!ncdump -h samples/l4_full_example.nc | grep $'[ , \t]analysed_sst[(,:]'| sed 's/[[:space:]]//'
```
(__l4_analysis_error)=
## `analysis_error`
The variable `analysis_error` will be included with the format requirements
shown in {numref}`l4_analysis_error`.
The data provider is responsible for providing GHRSST with documentation on how
`analysis_error` is determined.
```{table} CDL example description of analysis\_error variable
:name: l4_analysis_error
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|----------------|-------------------------------------|----------|
| short | `analysis_error` | Error estimate from analysis system | K (kelvin) |
```
```{code-cell}
:tags: [remove-input]
!ncdump -h samples/l4_full_example.nc | grep $'[ , \t]analysis_error[(,:]'| sed 's/[[:space:]]//'
```
(__l4_sea_ice_fraction)=
## `sea_ice_fraction`
The variable sea_ice_fraction will be included with the format requirements
shown in {numref}`l4_sea_ice_fraction`.
Some SST data are contaminated in part or wholly by sea ice and the L4 variable
`sea_ice_fraction` is used to quantify the fraction of an area contaminated
with sea ice. If the error estimates on the sea ice field are available, it
is recommended to provide this information as an experimental variable called
`sea_ice_fraction_error`.
```{table} CDL example description of **sea\_ice\_fraction** variable
:name: l4_sea_ice_fraction
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|------------------|---------------------------------------|-----------|
| byte | `sea_ice_fraction` | Fractional sea ice area concentration | 1 (unitless) |
```
```{code-cell}
:tags: [remove-input]
!ncdump -h samples/l4_full_example.nc | grep $'[ , \t]sea_ice_fraction[(,:]'| sed 's/[[:space:]]//'
```
(__l4_mask)=
## `mask`
The variable `mask` will be included with the format requirements shown in {numref}`l4_mask`.
```{table} CDL example description of **mask** variable
:name: l4_mask
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|----------|------------------------|----------|
| byte | `mask` | land/sea/ice/lake mask | none |
```
```{code-cell}
:tags: [remove-input]
!ncdump -h samples/l4_full_example.nc | grep $'[ , \t]mask[(,:]'| sed 's/[[:space:]]//'
```
```{admonition} Comments:
Comments
This is a land/sea/ice mask with the following bit values:
- Bit 0:1 = water in grid
- Bit 1:1 = land in grid
- Bit 2:1 = optional, lake surface in grid
- Bit 3:1 = sea ice
- Bit 4:1 = optional, river surface in grid
- Bits [5-7] spare
Note that the lake and river surface bit values are optional.
The `source` attribute should list any data product used in creating this
mask, a semi-colon separated list of identifiers
**\\_\\_\**.
```
(__l4_sea_ice_fraction_error)=
## Optional Variable **sea_ice_fraction_error**
If the error estimates on the sea ice field are available, it is recommended
to provide this information as an optional field called
`sea_ice_fraction_error`. The data provider is responsible for providing
GHRSST with documentation on how `sea_ice_fraction_error` is estimated.
```{table} CDL example description of **sea_ice_fraction_error** variable
:name: l4_sea_ice_fraction_error
| **Storage type** | **Name** | **Description** | **Unit** |
|-------------------|------------------------|---------------------------------------|-----------|
| byte | `sea_ice_fraction_error` | Fractional sea ice area concentration error | 1 |
```
```{code-cell}
:tags: [remove-input]
!ncdump -h samples/l4_full_example.nc | grep $'[ , \t]sea_ice_fraction_error[(,:]'| sed 's/[[:space:]]//'
```
(__l4_optional_fields)=
### Optional experimental L4 variables included by data provider
Flexibility of L4 product content is provided through the netCDF API, which
allows fully self-describing fields and additional L4 variables may be included
by L4 data providers if they are considered relevant for L4 users. The GDS-{{gds_version}}
also permits the inclusion of R&D variables (e.g. estimates of sea
ice fraction error, SST anomaly, etc.) and 6 bytes per pixel are available in
total for optional/experimental variables in any combination (i.e., variables
can be defined as 6 x byte, 3 x short, 2 x short + 2 x byte, etc). The use of
optional/experimental variables provides a limited amount of flexibility within
the GDS-{{gds_version}} for regional user requirements while maintaining an overall upper
limit on GDS-{{gds_version}} L4 products for data management groups and
archive scaling. In exceptional cases a waiver on the 6 byte ceiling can be
requested to extend up to 12 bytes per pixel.
The GDS-{{gds_version}} issues the following guidance on the inclusion of optional or
experimental variables within L4 data products:
- The sum total of all experimental variables shall not increase L4 record
size by more than **6 bytes** per SST pixel. A **waiver** can be requested
for higher amounts up to 12 bytes.
- CF-1.7 or later compliance should be maintained for all
optional/experimental variables. Where available, a standard_name
attribute should be used.
- It is permitted to use a provider defined coordinate variable associated
with experimental fields but this shall be documented in data provider
documentation.
- Time difference data (dtime values) should be provided for variables when
appropriate.
- The source of data should be indicated: in the single source case as a
variable attribute; as a dedicated variable when mixed data sources are
present.
- Use of experimental variables requires clear documentation by the GHRSST
producer. They shall provide adequate documentation that describes each
variable following the CDL examples provided in this document.
- The variable attribute `comment` shall be used to provide a URL link to a
full description of each data producer defined variable included in the
L4 product.
- Experimental L4 variables if present in an L4 product will be included
with the minimum format requirements shown in {numref}`__l4_sea_ice_fraction_error`
- Additional global variables may be declared within the L4 product.
## CDL example L4 dataset
The following CDL has been generated for a detailed example global L4 dataset:
```{code-cell}
:tags: [remove-input]
!ncdump -h samples/l4_full_example.nc
```
_sources/coordinates.md 0000664 0001750 0001750 00000031440 14714712730 015740 0 ustar jfpiolle jfpiolle ---
jupytext:
formats: md:myst
text_representation:
extension: .md
format_name: myst
---
(coordinate_variables)=
# Coordinate variables
NetCDF coordinate variables provide scales for the space and time axes for the
multidimensional data arrays, and must be included for all dimensions that can
be identified as spatio-temporal axes.
Coordinate arrays are used to geolocate
data arrays on non-orthogonal grids, such as images in the original pixel/scan
line space, or complicated map projections. Required attributes are `units` and
`_FillValue`. Elements of the coordinate array need not be monotonically
ordered. The data type can be any and scaling may be implemented if required.
`add_offset` and `scale_factor` have to be adjusted according to the sensor
resolution and the product spatial coverage. If the packed values can not stand
on a short, float can be used instead (multiplying the size of these variables
by two).
## Temporal coordinates
`time` is the reference time of the SST data array. The GDS-{{gds_version}}
specifies that this reference time should be extracted or computed to the
nearest second and then coded as continuous UTC time coordinates in
**seconds from 00:00:00 UTC January 1, 1981** (which is the definition of the
GHRSST origin time, chosen to approximate the start of useful AVHRR SST data
record). Note that the use of UDUNITS in GHRSST implies that that calendar to
be used is the default mixed Gregorian/Julian calendar.
The reference time used is dependent on the of the data and
is defined as follows:
| Processing level | Reference time |
|------------------|-------------------------------------|
| L2P | start time of granule |
| L3U | start time of granule |
| L3C | centre time of the collation window |
| L3S | centre time of the collation window |
| L4 | nominal time of the analysis |
The coordinate variable `time` is intended to minimize the size of the
`sst_dtime` variable (e.g., see {numref}`__l2p_sst_dtime`), which stores
offsets from the reference time in seconds for each SST pixel. `time` also
facilitates aggregation of all files of a given dataset along the time axis with
such tools as THREDDS or when building data cubes.
## Spatial coordinates
**x** (columns) and **y** (lines) grid dimensions are referred either as `lat`
and `lon` or as `ni` and `nj`. `lon` and `lat` must be used if data are mapped
on a regular grid (some geostationary products). `ni` and `nj` are used if data
are mapped on a non-regular grid (curvilinear coordinates) or following the
sensor scanning pattern (scan line, swath). It is preferred that `ni` should be
used for the across-track dimension and `nj` for the along-track dimension.
Coordinate vectors are used for data arrays located on orthogonal (but not
necessarily regularly spaced) grids, such as a geographic (lat-lon) map
projections. The only required attribute is `units`. The elements of a
coordinate vector array should be in monotonically increasing or decreasing
order. The data type can be any and scaling may be implemented if required.
A `coordinates` variable attribute (`coordinates = "lon lat" ;`) must be
provided if the data are on a non-regular lat/lon grid (map projection or
swath data).
A `grid_mapping` variable attribute (`grid_mapping = "" ;`)
must be provided if the data are mapped following a projection. Refer to the
CF convention[^footnote2] for standard projection names.
```{admonition} Note on lat/lon arrays
`lat` and `lon` arrays are the only arrays stored as float in GHRSST product
files and therefore can represent a major fraction of the overall data
volume. As an optimization factor, producers are encouraged to make use of the
`least_significant_digit` argument when creating these NetCDF variables (refer
for instance to https://unidata.github.io/netcdf4-python/): in most current
GHRSST products, there is no need for a precision larger than 3 digits and
it can be a big volume saver.
```
### Regular latitude/longitude grids
This is the simplest case. Many Level 3 and Level 4 products as well as some
geostationary L2P products are provided on a regular lat/lon grid. On such a
projection, only two coordinate variables are requested and they can be stored
as vector arrays. Longitudes should range from -180 to +180, corresponding to
180 degrees West to 180 degrees East. Latitudes should range from -90 to +90,
corresponding to 90 degrees South to 90 degrees North. There should be no
`_FillValue` for latitude and longitude and all SST pixels should have a valid
latitude and longitude value.
It is recommended that for Level 3 and Level 4 data products the `time`
dimension be specified as **unlimited**. Note that the `time` dimension for L2P
data files is strictly defined as `time=1` (unlimited dimension not allowed).
This strict definition is because L2P data are swath based and the geospatial
information may change across consecutive time slabs. Although in GHRSST L3 and
L4 granules there is only one `time` dimension and variable `time` has only one
value (seconds since 1981), setting an unlimited dimension for `time` dimension
will allow netCDF tools and utilities to easily concatenate (and average for
example) a series of time consecutive GHRSST granules. The following CDL is
provided as an example:
```
netcdf example {
dimensions:
lat = 1801 ;
lon = 3600 ;
time = UNLIMITED ; // (strictly set to 1 for L2P)
variables:
...
}
```
For these cases, dimension and coordinate variables shall be used for a regular
lat/lon grid as shown in {numref}`regular_grid_coords`. No specific variable
attributes are required for other variables (like `sea_surface_temperature` as
shown in the example given in {numref}`regular_grid_coords`).
```{table} Example CDL for geographic regular latitude/longitude grids
:name: regular_grid_coords
| geographic regular latitude/longitude grids |
| -------------------------------------------------- |
```
```{code-cell}
:tags: [remove-input]
:name: regular_grid_coords
!ncdump -h samples/regular_grid.nc
```
### Non-regular latitude/longitude grids (projection)
For gridded data using a specific projection (such as stereographic projection),
lat/lon have to be stored in 2-D arrays. When data are gridded following the
sensor pattern, no projection can be associated and lat/lon data have to be
stored in 2-D arrays. Dimensions cannot be referred to as lat/lon anymore since
the **x** and **y** axes of the grid are not related to the latitude or
longitude axis. Each variable must explicitly provide a reference to its
coordinate variables (`coordinates` variable attribute) and to the related
projection (`grid_mapping` variable attribute) described in a specific variable
(for example, `Lambert_Azimuthal_Grid",` in the example given in
{numref}`non_regular_grid_coords_projection`, refer to CF convention
[^footnote2] for standard projection names).
In these cases, dimension and coordinate variables shall be used for a
non-regular lat/lon grid (projection) as shown in
{numref}`non_regular_grid_coords_projection`. A specific projection coordinate
variable shall be added (for example, `Lambert_Azimuthal_Grid`), following the
CF-1.7 or later convention. The specific variable attributes
`coordinates = "lon lat"` and`grid_mapping = "Lambert_Azimuthal_Grid"` are
required for each other variables (like `sea_surface_temperature` in the example
given in {numref}`non_regular_grid_coords_projection`).
Note that variable attributes such as `grid_mapping` may be set differently
(when using a different kind of projection) or completely removed (for swath
products or regular grids if required).
```{table} Example CDL for non-regular latitude/longitude grids (projection)
:name: non_regular_grid_coords_projection
| non-regular latitude/longitude grids (projections) |
| -------------------------------------------------- |
```
```{code-cell}
:tags: [remove-input]
:name: non_regular_grid_coords_projection
!ncdump -h samples/nonregular_grid_projection.nc
```
### Non-regular latitude/longitude grids (projection) – alternative without explicit latitude/longitude
For gridded data using a fixed specific projection (such as geostationary
projection), the same lat/lon 2-D arrays are repeated from file to file. If a
fixed projection can be associated to lat/lon data, it is also permitted by CF
convention to provide a projection variable defining this projection, instead of
providing explicit latitude/longitude 2-D arrays as in the previous section.
This usually allows to save significant storage (which is interesting for
products with a high temporal repetitiveness such as geostationary products in
satellite projection) while being less user friendly since users will have to
calculate their own latitude/longitude 2-D arrays from the projection parameters
(this is done automatically in some CF compliant tools). The projection variable
must be named with the projection name used in the product (like `geostationary`
below). It is dimensionless and of type int. The naming and content of this
projection variable is described in CF conventions[^footnote2].
The **x** (abscissa) and **y** (ordinate) rectangular coordinates must be
provided in `ni` and `nj` variables, identified by the `standard_name`attribute
values `projection_x_coordinate` and `projection_y_coordinate` respectively.
In the case of this geostationary projection, the projection coordinates in this
projection are directly related to the scanning angle of the satellite
instrument, and their units are radians.
Each variable must explicitly provide a reference to its coordinate variables
(coordinates variable attribute) and to the related projection (`grid_mapping`
variable attribute) described in a specific variable (e.g. geostationary in the
example given in {numref}`non_regular_grid_coords_projection_no_latlon`; refer
to CF convention[^footnote2] for standard projection names).
In these cases, dimension and coordinate variables shall be used for a
non-regular lat/lon grid (projection) as shown in
{numref}`non_regular_grid_coords_projection_no_latlon`. A specific projection
coordinate variable shall be added (for example, `geostationary`), following the
CF-1.7 or later convention. The specific variable attributes
`coordinates = "nj ni"` and `grid_mapping = "geostationary"` are required for
each other variables (like `sea_surface_temperature` in the example given in
{numref}`non_regular_grid_coords_projection_no_latlon`).
```{table} Example CDL for Non-regular latitude/longitude grids (projections) alternative form with no explicit latitudes/longitudes
:name: non_regular_grid_coords_projection_no_latlon
| non-regular latitude/longitude grids (projections) with no explicit latitude/longitude |
| -------------------------------------------------- |
```
```{code-cell}
:tags: [remove-input]
:name: non_regular_grid_coords_projection_no_latlon
!ncdump -h samples/nonregular_grid_projection_no_latlon.nc
```
### Non-regular latitude/longitude grids (swath)
In this case where data are gridded following the sensor pattern, no projection
can be associated and lat/lon data have to be stored in 2-D arrays, as it is
the case for along-swath data for low earth orbiting sensors or geostationary
orbiting sensor data in their native projection. Therefore it only applies
to **L2P** processing level products.
Dimensions cannot be referred to as lat/lon anymore since x and y axes of the
grid are no more related to the latitude or longitude axis. Instead, dimensions
`ni` and `nj`should be used to describe the swath. As a best practice, the `ni`
dimension should refer to the cross-track direction and the `nj` dimension
should refer to the along-track direction of a polar orbiting (or similar)
satellite sensor swath. For geostationary sensors `ni` also refers to the
cross-disk direction and `nj` the along-disk direction. Each variable must
explicitly provide a reference to its coordinate variables (using the
coordinates variable attribute) and pixel times must be encoded using the
combination of `time`and `sst_dtime` coordinate variables.
Dimension and coordinate variables shall be used for a non-regular lat/lon grid
(swath product file) as shown in {numref}`non_regular_grid_coords`. The specific
variable attribute `coordinates = "lon lat"` is required for each of the
variables (like `sea_surface_temperature` below).
```{table} Example CDL for non-regular latitude/longitude grids (swath)
:name: non_regular_grid_coords
| non-regular latitude/longitude coordinates |
| ------------------------------------------ |
```
```{code-cell}
:tags: [remove-input]
:name: non_regular_grid_coords
!ncdump -h samples/nonregular_grid.nc
```
[^footnote2]: http://cfconventions.org/cf-conventions/cf-conventions.html#appendix-grid-mappings _sources/structure.md 0000664 0001750 0001750 00000275364 14726262110 015500 0 ustar jfpiolle jfpiolle # GDS Data Product File Structure and attributes
## Overview of the GDS-{{gds_version}} netCDF File Format
GDS-{{gds_version}} data files preferentially use the netCDF-4 Classic format. A
major advantage to the use of NetCDF-4 format products is that it offers
internal compression so that reading a given variable or some attributes
does not require to explicitly decompress the entire file.
These GDS-{{gds_version}} formatted data sets must comply with the **Climate
and Forecast (CF) Conventions, v1.7 or later** [^footnote1] because these
conventions provide a practical standard for storing oceanographic data in a robust,
easily-preserved for the long-term, and interoperable manner. The CF-compliant
netCDF data format is flexible, self-describing, and has been adopted as a de
facto standard for many operational and scientific oceanography systems.
Both netCDF and CF are actively maintained including significant discussions and
inputs from the oceanographic community. The CF convention generalizes and
extends the **Cooperative Ocean/Atmosphere Research Data Service (COARDS)
Convention** [^footnote2] but relaxes the COARDS constraints on dimension order
and specifies methods for reducing the size of datasets. The purpose of the CF
Conventions is to require conforming datasets to contain sufficient metadata so
that they are self-describing, in the sense that each variable in the file has
an associated description of what it represents, physical units if appropriate,
and that each value can be located in space (relative to earth-based
coordinates) and time. In addition to the CF Conventions, GDS-{{gds_version}}
formatted files follow some of the recommendations of the **Unidata Attribute
Convention for Dataset Discovery (ACDD)** [^footnote3].
In the context of netCDF, a **variable** refers to data stored in the file as a
vector or as a multidimensional array. Each variable in a GHRSST netCDF file
consists of a 2-dimensional `[i x j]`, 3-dimensional `[i x j x k]`, or
4-dimensional `[i x j x k x l]` array of data. The dimensions of each
variable must be explicitly declared in the dimension section.
Within the netCDF file, **global attributes** are used to hold information that
applies to the whole file, such as the data set title. Each individual variable
must also have its own attributes, referred to as **variable attributes**.
These variable attributes define, for example, an **offset**, **scale factor**,
**units**, a **descriptive version of the variable name**, and a **fill
value**, which is used to indicate array elements that do not contain valid
data. Where applicable, SI units should be used and described by a character
string, which is compatible with the Unidata UDUNITS-2 package [^footnote4].
All GHRSST GDS-{{gds_version}} files conform to this structure and share a
common set of netCDF global attributes. These global attributes include those
required by the CF Convention plus additional ones required by the
GDS-{{gds_version}}. The required set of global attributes is described in
{numref}`global_attributes` and entities within the GHRSST R/GTS framework are
free to add their own, as long as they do not contradict the
GDS-{{gds_version}} and CF requirements.
Following the CF convention, each variable also has a set of variable
attributes. The required variable attributes are described in
{numref}`variable_attributes`. In a few cases, some of these variable attributes
may not be relevant for certain variables or additional variable attributes may
be required. In those cases, the variable descriptions in each of the
[L2P](./l2p.md), [L3](./l3.md), [L4](./l4.md) product specifications will
identify the differences and specify requirements for each product. As with the
global attributes, entities within the GHRSST R/GTS framework are free to add
their own variable attributes, as long as they do not contradict the
GDS-{{gds_version}} and CF requirements.
While the exact volumes can vary, an average L2P file will use about 33 bytes
per pixel, an L3 file 28 bytes per pixel, and an L4 file about 8 bytes per
pixel. The data type encodings for each variable are fixed except for the
experimental fields, which are flexible and can chosen by the GHRSST producer.
(global_attributes)=
## Global Attributes
{numref}`__global_attributes` below summarizes the global attributes that are
mandatory for every GDS-{{gds_version}} netCDF data file. More details on the
CF-mandated attributes (as indicated in the *Source* column) are available at:
http://cfconventions.org/cf-conventions/cf-conventions.html#attribute-appendix
and information on the ACDD recommendations is available at
https://wiki.esipfed.org/Attribute_Convention_for_Data_Discovery_1-3.
```{table} Mandatory global attributes for GDS-{{gds_version}} netCDF data files (blue are mandatory, purple are optional)
:name: __global_attributes
:class: global-attributes-css
| Global Attribute Name | Format | Description | Example | Source |
|----------------------------------|---------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| ------ |
| `Conventions` | string | A comma-separated list of the conventions that are followed by the dataset. For files that follow this versionof ACDD, include the string 'ACDD-1.3'.(This attribute is defined in NUG 1.7.) | `Conventions = "CF 1.7+, ACDD 1.3 ISO 8601";` | ACDD 1.3 CF 1.7++ |
| `title` | string | A short phrase or sentence describing the dataset. In many discovery systems, the title will be displayed in the results list from a search, and therefore should be human readable and reasonable to display in a list of such names. This attribute is recommended by the NetCDF Users Guide (NUG) and the CF conventions. | `title = "VIIRS L2P Sea Surface Skin Temperature" ;` | ACDD 1.1 ACDD 1.3 CF 1.7+|
| `summary` | string | A paragraph describing the dataset, analogous to an abstract for a paper. | `summary = "Sea surface temperature (SST) retrievals produced at the NASA OBPG for the Visible Infrared Imaging Radiometer Suite (VIIRS) sensor on the Suomi National Polar-Orbiting Parnership (Suomi NPP) platform. These have been reformatted to GHRSST GDS version 2 Level 2P specifications by the JPL PO.DAAC." ;` | ACDD 1.1 ACDD 1.3 |
| `references` | string | Published or web-based references that describe the data or methods used to produce it. Recommend URIs (such as a URL or DOI) for papers or other references. This attribute is defined in the CF conventions. | `references = "GHRSST Data Processing Specification v2r5" ;` | ACDD 1.3 CF 1.7+ |
| `institution` | string | The name of the institution principally responsible for originating this data. This attribute is recommended by the CF convention. | `institution = "NASA Jet Propulsion Laboratory (JPL) Physical Oceanography Distributed Active Archive Center (PO.DAAC)/NASA Goddard Space Flight Center (GSFC), Ocean Biology Processing Group (OBPG)/University of Miami Rosential School of Marine and Atmospheric Science (RSMAS)" ;` |ACDD 1.1, ACDD 1.3 CF 1.7+|
| `history` | string | Provides an audit trail for modifications to the original data. This attribute is also in the NetCDF Users Guide: 'This is a character array with a line for each invocation of a program that has modified the dataset. Well-behaved generic netCDF applications should append a line containing: date, time of day, user name, program name and command arguments.' To include a more complete description you can append a reference to an ISO Lineage entity; see NOAA EDM ISO Lineage guidance. | `history = "VIIRS L2P created at JPL PO.DAAC by combining OBPG SNPP_SST and SNPP_SST3, and outputing to the GHRSST GDS2 netCDF file format" ;` | ACDD 1.1 ACDD 1.3 CF 1.7+ |
| `comment` | string | Miscellaneous information about the data, not captured elsewhere. This attribute is defined in the CF Conventions. | `comment = "L2P Core without DT analysis or other ancillary fields; Night, Start Node:Descending, End Node:Descending; WARNING Some applications are unable to properly handle signed byte values. If values are encountered > 127, please subtract 256 from this reported value; Quicklook" ;` | ACDD 1.1 ACDD 1.3 |
| `license` | string | Provide the URL to a standard or specific license, enter "Freely Distributed" or "None", or describe any restrictions to data access and distribution in free text. GHRSST data sets should be freely and openly available to comply with the R/GTS framework, with no restrictions. However, if a user should submit a simple registration via a web form, for example, the URL could be given here. | `license = "GHRSST protocol describes data use as free and open.” ;` | ACDD 1.1 ACDD 1.3|
| `id` | string | An identifier for the data set, provided by and unique within its naming authority. The combination of the ""naming authority"" and the ""id"" should be globally unique, but the id can be globally unique by itself also. IDs can be URLs, URNs, DOIs, meaningful text strings, a local key, or any other unique string of characters. The id should not include white space characters.
Here the unique GHRSST character string for this product. All GHRSST SST products have one, and they are listed in Erreur : source de la référence non trouvée. | `id = "VIIRS_NPP-JPL-L2P-v2016.0" ;` | ACDD 1.1 ACDD 1.3 |
| `naming_authority` | string | The organization that provides the initial id (see above) for the dataset. The naming authority should be uniquely specified by this attribute. We recommend using reverse-DNS naming for the naming authority; URIs are also acceptable. Fixed as “org.ghrsst” following ACDD convention. | `naming_authority = "org.ghrsst" ;` | ACDD 1.1 ACDD 1.3 |
| `product_version` | string | Version identifier of the data file or product as assigned by the data creator. For example, a new algorithm or methodology could result in a new product_version. It may be different than the file version used in the file naming convention (Section 7). | `product_version = "2016.0" ;` | ACDD 1.3 |
| `uuid` | string | A uuid (Universal Unique Identifier) is a 128-bit number used to uniquely identify some object or entity on the Internet. Depending on the specific mechanisms used, a uuid is either guaranteed to be different or is, at least, extremely likely to be different from any other uuid generated until 3400 A.D. See http://en.wikipedia.org/wiki/Universally_Unique_Identifier for more information and tools. | `uuid = "b6ac7651-7b02-44b0-942b-c5dc3c903eba" ;` | GDS |
| `gds_version_id` | string | GDS version used to create this data file. For example, “2.1”. | | GDS |
| `netcdf_version_id` | string | Version of netCDF libraries used to create this file. For example, “4.1.1” | | GDS |
| `date_created` | string | The date on which this version of the data was created. (Modification of values implies a new version, hence this would be assigned the date of the most recent values modification.) Metadata changes are not considered when assigning the date_created. The ISO 8601:2004 extended date format is recommended.
| `date_created = "2016-10-14T21:00:25" ;` | ACDD 1.1 ACDD 1.3 |
| `date_modified` | string | The date on which the data was last modified. Note that this applies just to the data, not the metadata. The ISO 8601:2004 extended date format is recommended.
| `date_modified = "2016-10-14T21:00:25" ;` | ACDD 1.1 ACDD 1.3 |
| `date_issued` | string | The date on which this data (including all modifications) was formally issued (i.e., made available to a wider audience). Note that these apply just to the data, not the metadata. The ISO 8601:2004 extended date format is recommended.
| `date_issued = "2016-10-14T21:00:25" ;` | ACDD 1.1 ACDD 1.3 |
| `date_metadata_modified` | string | The date on which the metadata was last modified. The ISO 8601:2004 extended date format is recommended.
| `date_metadata_modified = "2016-10-14T21:00:25" ;` | ACDD 1.3 |
| `file_quality_level` | integer | A code value: 0 = unknown quality 1 = extremely suspect (frequent problems, e.g. with known satellite problems) 2 = suspect (occasional problems, e.g. after launch) 3 = excellent (no known problems) | | GDS |
| `spatial_resolution` | string | A string describing the approximate resolution of the product. For example, “1.1km at nadir” | | GDS |
| `time_coverage_start` | string | Describes the time of the first data point in the data set. Use the ISO 8601:2004 date format, of “yyyy-mm-ddThh:mm:ssZ”. The exact meaning of this attribute depends the type of granule: L2P: first measurement in granule (identical to ‘time’ netCDF variable)
L3U: start time of granule
L3C and L3S: representative start time of first measurement in the collation
L4: representative start time of the analysis (start_time and stop_time together represent the valid period of the L4 granule)
| `time_coverage_start = "2016-09-01T08:12:01" ;` | ACDD 1.1 ACDD 1.3 |
| `time_coverage_end` | string | Describes the time of the last data point in the data set. Use ISO 8601:2004 date format, of “yyyy-mm-ddThh:mm:ssZ”. The exact meaning of this attribute depends the type of granule: L2P: last measurement in granule
L3U: stop time of granule
L3C and L3S: representative stop time of last measurement in collation
L4: representative stop time of the analysis (start_time and stop_time together represent the valid period of the L4 granule) | `time_coverage_end = "2016-09-01T08:17:59" ;` | ACDD 1.1 ACDD 1.3 |
| `instrument` | string | Name of the contributing instrument(s) or sensor(s) used to create this data set or product. Indicate controlled vocabulary used in instrument_vocabulary.
We recommend for consistency to use the CEOS mission table (http://database.eohandbook.com/database/instrumenttable.aspx). Provide as a comma separated list if there is more than one. | `sensor = "VIIRS" ;` | ACDD 1.3 |
| `instrument_vocabulary` | string | Controlled vocabulary for the names used in the ""instrument"" attribute. | `instrument_vocabulary = "CEOS instrument table" ;` | ACDD 1.3 |
| `metadata_link` | string | A URL that gives the location of more complete metadata. A persistent URL is recommended for this attribute. It is recommended to link to the product description in the GHRSST central catalogue. | `metadata_link = "http://podaac.jpl.nasa.gov/ws/metadata/dataset/?format=iso&shortName=VIIRS-JPL-L2P-v2016.0" ;` | ACDD 1.3 |
| `keywords` | string | A comma-separated list of key words and/or phrases. Keywords may be common words or phrases, terms from a controlled vocabulary (GCMD is often used), or URIs for terms from a controlled vocabulary (see also "keywords_vocabulary" attribute). | `keywords = "Oceans, Ocean Temperature, Sea Surface Temperature , Sea Surface Skin Temperature" ;` | ACDD 1.1 ACDD 1.3 |
| `keywords_vocabulary` | string | If you are using a controlled vocabulary for the words/phrases in your "keywords" attribute, this is the unique name or identifier of the vocabulary from which keywords are taken. If more than one keyword vocabulary is used, each may be presented with a prefix (e.g.,“NASA Global Change Master Directory (GCMD) Science Keywords” as defined in [AD-10]) and a following comma, so that keywords may optionally be prefixed with the controlled vocabulary key. | `keywords_vocabulary = "NASA Global Change Master Directory (GCMD) Science Keywords" ;`[AD-10] | ACDD 1.1 ACDD 1.3 |
| `standard_name_vocabulary` | string | The name and version of the controlled vocabulary from which variable standard names are taken. (Values for any standard_name attribute must come from the CF Standard Names vocabulary for the data file or product to comply with CF.) | CF Standard Name Table v27'. | ACDD 1.1 ACDD 1.3 |
| `geospatial_lat_min` | float | Describes a simple lower latitude limit; may be part of a 2- or 3-dimensional bounding region. Geospatial_lat_min specifies the southernmost latitude covered by the dataset.
| `geospatial_lat_min = -63.1404f ;` | ACDD 1.1 ACDD 1.3 |
| `geospatial_lat_max` | float | Describes a simple upper latitude limit; may be part of a 2- or 3-dimensional bounding region. Geospatial_lat_max specifies the northernmost latitude covered by the dataset. | `geospatial_lat_max = -36.7432f ;` | ACDD 1.1 ACDD 1.3 |
| `geospatial_lat_units` | string | Units for the latitude axis described in ""geospatial_lat_min"" and ""geospatial_lat_max"" attributes. These are presumed to be ""degree_north""; other options from udunits may be specified instead. | `geospatial_lat_units = "degrees_north" ;` | ACDD 1.1 ACDD 1.3 |
| `geospatial_lat_resolution` | float | Information about the targeted spacing of points in latitude. Recommend describing resolution as a number value followed by the units. Examples: '100 meters', '0.1 degree'. For level 1 and 2 swath data this is an approximation of the pixel resolution. | `geospatial_lat_resolution = 0.0075f ;` | ACDD 1.1 ACDD 1.3 |
| `geospatial_lon_min` | float | Describes a simple longitude limit; may be part of a 2- or 3-dimensional bounding region. geospatial_lon_min specifies the westernmost longitude covered by the dataset. See also geospatial_lon_max. | `geospatial_lon_min = -143.09f ;` | ACDD 1.1 ACDD 1.3 |
| `geospatial_lon_max` | float | Describes a simple longitude limit; may be part of a 2- or 3-dimensional bounding region. geospatial_lon_max specifies the easternmost longitude covered by the dataset. Cases where geospatial_lon_min is greater than geospatial_lon_max indicate the bounding box extends from geospatial_lon_max, through the longitude range discontinuity meridian (either the antimeridian for -180:180 values, or Prime Meridian for 0:360 values), to geospatial_lon_min; for example, geospatial_lon_min=170 and geospatial_lon_max=-175 incorporates 15 degrees of longitude (ranges 170 to 180 and -180 to -175). | `geospatial_lon_max = -88.893f ;` | ACDD 1.1 ACDD 1.3 |
| `geospatial_lon_units` | string | Units for the longitude axis described in ""geospatial_lon_min"" and ""geospatial_lon_max"" attributes. These are presumed to be ""degree_east""; other options from udunits may be specified instead. | `geospatial_lon_units = "degrees_east" ;` | ACDD 1.1 ACDD 1.3 |
| `geospatial_lon_resolution` | float | Information about the targeted spacing of points in longitude. Recommend describing resolution as a number value followed by units. Examples: '100 meters', '0.1 degree'. For level 1 and 2 swath data this is an approximation of the pixel resolution. | `geospatial_lon_resolution = 0.0075f ;` | ACDD 1.1 ACDD 1.3 |
| `geospatial_vertical_min` | float | Describes the numerically smaller vertical limit; may be part of a 2- or 3-dimensional bounding region. See geospatial_vertical_positive and geospatial_vertical_units. | `geospatial_vertical_min = 0.00f ;` | ACDD 1.1 ACDD 1.3 |
| `geospatial_vertical_max` | float | Describes the numerically larger vertical limit; may be part of a 2- or 3-dimensional bounding region. See geospatial_vertical_positive and geospatial_vertical_units. | `geospatial_vertical_max = 1000.00f ;` | ACDD 1.1 ACDD 1.3 |
| `geospatial_vertical_resolution` | float | Information about the targeted vertical spacing of points. Example: '25 meters' | `geospatial_vertical_resolution = 25.0f ;` | ACDD 1.1 ACDD 1.3 |
| `geospatial_vertical_units` | string | Units for the vertical axis described in "geospatial_vertical_min" and "geospatial_vertical_max" attributes. The default is EPSG:4979 (height above the ellipsoid, in meters); other vertical coordinate reference systems may be specified. Note that the common oceanographic practice of using pressure for a vertical coordinate, while not strictly a depth, can be specified using the unit bar. Examples: 'EPSG:5829' (instantaneous height above sea level), 'EPSG:5831' (instantaneous depth below sea level). | `geospatial_vertical_units = 'meters' ;` | ACDD 1.1 ACDD 1.3 |
| `geospatial_vertical_positive` | string | One of 'up' or 'down'. If up, vertical values are interpreted as 'altitude', with negative values corresponding to below the reference datum (e.g., under water). If down, vertical values are interpreted as 'depth', positive values correspond to below the reference datum. Note that if geospatial_vertical_positive is down ('depth' orientation), the geospatial_vertical_min attribute specifies the data's vertical location furthest from the earth's center, and the geospatial_vertical_max attribute specifies the location closest to the earth's center. | `geospatial_vertical_positive = 'down' ;` | ACDD 1.1 ACDD 1.3 |
| `geospatial_bounds` | string | Describes the data's 2D or 3D geospatial extent in OGC's Well-Known Text (WKT) Geometry format (reference the OGC Simple Feature Access (SFA) specification). The meaning and order of values for each point's coordinates depends on the coordinate reference system (CRS). The ACDD default is 2D geometry in the EPSG:4326 coordinate reference system. The default may be overridden with geospatial_bounds_crs and geospatial_bounds_vertical_crs (see those attributes). EPSG:4326 coordinate values are latitude (decimal degrees_north) and longitude (decimal degrees_east), in that order. Longitude values in the default case are limited to the (-180, 180) range. Example: "POLYGON ((40.26 -111.29, 41.26 -111.29, 41.26 -110.29, 40.26 -110.29, 40.26 -111.29))". | `geospatial_bounds = "(-143.09, -63.1404, -88.893, -36.7432)" ;` | ACDD 1.1 ACDD 1.3 |
| `geospatial_bounds_crs` | string | The coordinate reference system (CRS) of the point coordinates in the geospatial_bounds attribute. This CRS may be 2-dimensional or 3-dimensional, but together with geospatial_bounds_vertical_crs, if that attribute is supplied, must match the dimensionality, order, and meaning of point coordinate values in the geospatial_bounds attribute. If geospatial_bounds_vertical_crs is also present then this attribute must only specify a 2D CRS. EPSG CRSs are strongly recommended. If this attribute is not specified, the CRS is assumed to be EPSG:4326. Examples: "EPSG:4979" (the 3D WGS84 CRS), "EPSG:4047". | `geospatial_bounds_crs = "WGS84" ;` | ACDD 1.3 |
| `geospatial_bounds_vertical_crs` | string | The vertical coordinate reference system (CRS) for the Z axis of the point coordinates in the geospatial_bounds attribute. This attribute cannot be used if the CRS in geospatial_bounds_crs is 3-dimensional; to use this attribute, geospatial_bounds_crs must exist and specify a 2D CRS. EPSG CRSs are strongly recommended. There is no default for this attribute when not specified. Examples: ""EPSG:5829"" (instantaneous height above sea level), ""EPSG:5831"" (instantaneous depth below sea level), or ""EPSG:5703"" (NAVD88 height). | `geospatial_bounds_vertical_crs = "EPSG:5831" ;` | ACDD 1.3 |
| `acknowledgment` | string | A place to acknowledge various types of support for the project that produced this data. | `acknowledgment = "The VIIRS L2P sea surface temperature data are sponsored by NASA. Data may be freely distributed" ;` | ACDD 1.1 ACDD 1.3 |
| `creator_name` | string | The name of the person (or other creator type, such as a RDAC, specified by the creator_type attribute) principally responsible for creating this data. | `creator_name = "JPL PO.DAAC" ;` | ACDD 1.1 ACDD 1.3 |
| `creator_url` | string | The URL of the of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data. | `creator_url = "http://podaac.jpl.nasa.gov" ;` | ACDD 1.1 ACDD 1.3 |
| `creator_email` | string | The email address of the person (or other creator type specified by the creator_type attribute) principally responsible for creating this data. | `creator_email = "ghrsst@jpl.nasa.gov" ;` | ACDD 1.1 ACDD 1.3 |
| `creator_type` | string | Specifies type of creator with one of the following: 'person', 'group', 'institution', or 'position'. If this attribute is not specified, the creator is assumed to be a person. For a RDAC, use here ‘institution’. | `creator_type = "institution" ;` | ACDD 1.3 |
| `creator_institution` | string | The institution of the creator; should uniquely identify the creator's institution. This attribute's value should be specified even if it matches the value of publisher_institution, or if creator_type is institution. | `creator_institution = "JPL PO.DAAC/GHRSST";` | ACDD 1.3 |
| `project` | string | The name of the project(s) principally responsible for originating this data. Multiple projects can be separated by commas, as described under Attribute Content Guidelines. Examples: 'PATMOS-X', 'Extended Continental Shelf Project'.
| `"Group for High Resolution Sea Surface Temperature” ;` | ACDD 1.1 ACDD 1.3 |
| `program` | string | The overarching program(s) of which the dataset is a part. A program consists of a set (or portfolio) of related and possibly interdependent projects that meet an overarching objective. Examples: 'GHRSST', 'NOAA CDR', 'NASA EOS', 'JPSS', 'GOES-R'.
| `program= " NASA Earth Science Data Information and System (ESDIS)" ;` | ACDD 1.3 |
| `contributor_name` | string | The name of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to changes in whitespace, including end-of-line characters). | `contributor_name = "PO.DAAC/OBPS/REMAS" ;` | ACDD 1.3 |
| `contributor_role` | string | The role of any individuals, projects, or institutions that contributed to the creation of this data. May be presented as free text, or in a structured format compatible with conversion to ncML (e.g., insensitive to changes in whitespace, including end-of-line characters). Multiple roles should be presented in the same order and number as the names in contributor_names. | `contributor_role = "PO.DAAC convert the VIIRSS_NPP SST to GDS2 format, OBPS processed the L2P SST, and RSMAS provided the algorithm model ";` | ACDD 1.3 |
| `publisher_name` | string | The name of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format. | `publisher_name = "The GHRSST Project Office" ;` | ACDD 1.1 ACDD 1.3 |
| `publisher_url` | string | The URL of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format. | `publisher_url = "http://www.ghrsst.org" ;` | ACDD 1.1 ACDD 1.3 |
| `publisher_email` | string | The email address of the person (or other entity specified by the publisher_type attribute) responsible for publishing the data file or product to users, with its current metadata and format. | `publisher_email = "ghrsst-po@nceo.ac.uk" ;` | ACDD 1.1 ACDD 1.3 |
| `publisher_type` | string | Specifies type of publisher with one of the following: 'person', 'group', 'institution', or 'position'. If this attribute is not specified, the publisher is assumed to be a person. | `publisher_type = "institution" ;` | ACDD 1.3 |
| `publisher_institution` | string | The institution that presented the data file or equivalent product to users; should uniquely identify the institution. If publisher_type is institution, this should have the same value as publisher_name. | `publisher_institution = "PO.DAAC" ;` | ACDD 1.3 |
| `processing_level` | string | A textual description of the processing (or quality control) level of the data.
GHRSST definitions are the options: L2P, L3U, L3C, L3S, L4 and GMPE | `processing_level = "L2P" ;` | ACDD 1.1 ACDD 1.3 |
| `cdm_data_type` | string | The data type, as derived from Unidata's Common Data Model Scientific Data types and understood by THREDDS. (This is a THREDDS ""dataType"", and is different from the CF NetCDF attribute 'featureType', which indicates a Discrete Sampling Geometry file in CF.). “swath” or “grid”. | `cdm_data_type = "swath" ;` | ACDD 1.1 ACDD 1.3 |
```
(variable_attributes)=
## Variable Attributes
```{table} Variable attributes for GDS-2.1 netCDF data files (blue are mandatory, purple are optional, orange are deprecated attributes from previous GDS versions)
:name: var_attributes
:class: "var-attributes-css"
| Variable Attribute Name | Format | Description | | Source |
|-------------------------|---------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------|----------------------------|
| `_FillValue` | Must be the same as the packed variable type | Assigned value in the data file designating a null or missing observation. This value must be of the same type as the storage (packed) type; should be set as the minimum value for this type. Note that some netCDF readers are unable to cope with signed bytes and may, in these cases, report fill as 128. Some cases will be reported as unsigned bytes 0 to 255. Required for the majority of variables except mask and l2p_flags. Best practices specifies that for satellite datasets there should not be a `_FillVlalue` for geolocation or time variables. | `_FillValue = -32767s ;` | CF 1.7+ |
| `units` | String | The units of the variable's data values. This attribute value should be a valid udunits[^footnote6] string. The `units` attribute is recommended by the NetCDF Users Guide, the COARDS convention, and the CF convention. For a given variable (e.g. wind speed), these must be the same for each dataset. Required for the majority of variables except mask, quality_level, and l2p_flags. | `units = "K" ;` | ACDD 1.1 ACDD 1.3 CF 1.7+ |
| `scale_factor` | Must be expressed in the unpacked data type | Slope of scaling relationship applied to transform measuement data to appropriate geophysical quantity representations. Should not be used if the `scale_factor` is '1' and `add_offset` is '0' To be multiplied by the variable to recover the original value. Defined by the producer. Valid values within `value_range` should be transformed by scale_factor and add_offset, otherwise skipped to avoid floating point errors. |`scale_factor = 0.005f ;` | CF 1.7+ |
| `add_offset` | Must be expressed in the unpacked data type | Intercept of scaling relationship applied to transform measurement data to appropriate geophysical quantity representations. Should not be used if the `scale_factor` is '1' and `add_offset` is '0' To be added to the variable after multiplying by the scale factor to recover the original value. If only one of `scale_factor` or `add_offset` is needed, then both should be included anyway to avoid ambiguity, with `scale_factor` defaulting to 1.0 and `add_offset` defaulting to 0.0. Defined by the producer. Valid values within `value_range` should be transformed by `scale_factor` and `add_offset`, otherwise skipped to avoid floating point errors. | `add_offset = 273.15f ;` | CF 1.7+ |
| `long_name` | String | A long descriptive name for the variable (not necessarily from a controlled vocabulary). This attribute is recommended by the NetCDF Users Guide, the COARDS convention, and the CF convention. | `long_name = "sea surface temperature" ;` | ACDD 1.1 ACDD 1.3 CF 1.7+ |
| `valid_range` | Must be the same as the packed variable type | Comma separated minimum and maximum values of the physical quantity defining the valid measurement range. The fill value should be outside this valid range. Note that some netCDF readers are unable to cope with signed bytes and may, in these cases, report valid min as 129. Some cases as unsigned bytes 0 to 255. Values outside of the `valid_range` will be treated as missing values. When all values except the one in `_FillValue` are valid, this attribute is not required. It is therefore not necessary in GDS for variables for which the `_FillValue` attribute is defined. | `valid_range = -32767s, 32767 ;` | CF 1.7+ |
| `standard_name` | String | A long descriptive name for the variable taken from a controlled vocabulary of variable names. We require using the CF convention and the variable names from the CF standard name table[^footnote7]. This attribute is recommended by the CF convention. Do not include this attribute if no standard_name exists. | `standard_name = "sea_surface_skin_temperature" ;` | ACDD 1.1 ACDD 1.3 CF 1.7+ |
| `comment` | String | Optional attribute field allowing provision of further free-form information about the variable or the methods used to produce it. | `comment = "sea surface temperature from 11 and 12 um (thermal IR) channels" ;` | CF 1.7+ |
| `source` | string | For L2P and L3 files: For a data variable with a single source, use the GHRSST unique string if the source is a GHRSST SST product. For other sources, following the best practice described in Section {numref}`product_codes` to create the character string. If the data variable contains multiple sources, set this string to be the relevant “source of” variable name. For example, if multiple wind speed sources are used, set `source = source_of_wind_speed`.
For L4 and GMPE files: follow the source convention used for the global attribute of the same name, but provide in the comma-separated list only the sources relevant to this variable. | `source = "ECMWF" ;` | CF 1.7+ |
| `references` | string | Published or web-based references that describe the data or methods used to produce it. Note that while at least one reference is required in the global attributes (See {numref}`global_attributes`), references to this specific data variable may also be given. | | CF 1.7+ |
| `axis` | String | Corresponding variable axis for plotting (eg. X, Y, Z). For use with coordinate variables only. The attribute `axis` may be attached to a coordinate variable and given one of the values “X”, “Y”, “Z”, or “T”, which stand for a longitude, latitude, vertical, or time axis respectively[^footnote1]. | `axis = "Y";` | CF 1.7+ |
| `positive` | String | For use with a vertical coordinate variables only. May have the value “up” or “down”. For example, if an oceanographic netCDF file encodes the depth of the surface as 0 and the depth of 1000 meters as 1000 then the axis would set positive to “down”. If a depth of 1000 meters was encoded as -1000, then positive would be set to “up”. See the section on vertical coordinate in CF Convention[^footnote1] | `positive = "up" ;` | CF 1.7+ |
| `coordinates` | String | This attribute contains a space separated list of all the coordinates corresponding to the variable. The list should contain all the auxiliary coordinate variables and optionally the coordinate variables.
See the section on coordinate system in CF Convention[^footnote1]. This attribute must be provided if the data are on a non-regular lat/lon grid (map projection or swath data). | `coordinates = "time lat lon";` | CF 1.7+ |
| `grid_mapping` | String | Describes the horizontal coordinate system used by the data. The grid_mapping attribute should point to a variable which would contain the parameters corresponding to the coordinate system. That named variable is called a grid mapping variable and is of arbitrary type since it contains no data. Its purpose is to act as a container for the attributes that define the mapping. There are typically several parameters associated with each coordinate system. CF defines a separate attributes for each of the parameters. Some examples are `semi_major_axis`, `inverse_flattening`, `false_easting`. See the section on mappings-and-projections in CF Convention[^footnote1]. | `grid_mapping = "geostationary";` | CF 1.7+ |
| `flag_meanings` | String | Define the physical meaning of each `flag_masks` bit field or `flag_values` value with a single text string. | `flag_meanings = "microwave land ice lake river" ;` | CF 1.7+ |
| `flag_values` | Must be the same as the variable type | Its values identify the flagged conditions by performing a bitwise AND of the variable value and each flag masks value. For example, if the variable value is of type unsigned byte and equal to 5 and the flag_masks are 1b, 2b, 4b, 8b, 16b, 32b. The binary encoding of 5 is 00000101 and the binary encoding of the flags are 00000001, 00000010, 00000100, 00001000, 00010000, 00100000. Now bitwide AND of the value with the masks returns 00000001, 00000000, 00000100, 00000000, 00000000, 00000000 respectively or 1b,0,4b,0,0,0,0,0 in decimal. So the masks corresponding to 1b and 4b are ""true"", rest are ""false"". Used primarily for quality_level and “source_of_xxx” variables. | `flag_values = 1b, 5b ;` | CF 1.7+ |
| `flag_masks` | Must be the same as the variable type | A number of independent Boolean conditions using bit field notation by setting unique bits in each `flag_masks` value. The `flag_masks` attribute is the same type as the variable to which it is attached, and contains a list of values matching unique bit fields. (CF document, Flags section[^footnote1]). Used primarily for `l2p_flags` variable. | `flag_masks = 1b, 2b, 4b, 8b, 16b;` | CF 1.7+ |
| `depth` | String | Use this to indicate the depth for which the SST data are valid. | `depth= "1m" ;` | GDS |
| `height` | String | Use this to indicate the height for which the wind data are specified. | `height= "10m" ;` | GDS |
| `time_offset` | float | Difference in hours between an ancillary field such as wind_speed and the SST observation time | `time_offset= 3. ;` | GDS |
| `coverage_content_type` | String | An ISO 19115-3 code to indicate the source of the data `MD_CoverageContentTypeCode` [^footnote5]. For example, `image`, `thematicClassification`, `physicalMeasurement`, `auxiliaryInformation`, `qualityInformation`, `referenceInformation`, `modelResult`, or `coordinate`. | `coverage_content_type = "physicalMeasurement" ;` | ACDD 1.1 ACDD 1.3 |
```
[^footnote1]: netCDF Climate and Forecast (CF) Metadata Conventions version 1.7
or later available from http://cfconventions.org
[^footnote2]: COARDS Conventions available from
https://ferret.pmel.noaa.gov/Ferret/documentation/coards-netcdf-conventions
[^footnote3]: Unidata Attribute Conventions for Dataset Discovery (ACDD),
available from
https://wiki.esipfed.org/Attribute_Convention_for_Data_Discovery_1-3
[^footnote4]: UDUNITS-2 package available from
https://www.unidata.ucar.edu/software/udunits/
[^footnote5]: https://geonetwork-opensource.org/manuals/3.10.x/en/annexes/standards/iso19115-3.2018.html#standard-codelists-coverage-content-mrc-md-coveragecontenttypecode
[^footnote6]: http://www.unidata.ucar.edu/software/udunits/udunits-1/udunits.txt
[^footnote7]: http://cfconventions.org/Data/cf-standard-names/current/build/cf-standard-name-table.html _sphinx_design_static/ 0000775 0001750 0001750 00000000000 14744715173 015637 5 ustar jfpiolle jfpiolle _sphinx_design_static/design-tabs.js 0000664 0001750 0001750 00000005334 14744715173 020402 0 ustar jfpiolle jfpiolle // @ts-check
// Extra JS capability for selected tabs to be synced
// The selection is stored in local storage so that it persists across page loads.
/**
* @type {Record}
*/
let sd_id_to_elements = {};
const storageKeyPrefix = "sphinx-design-tab-id-";
/**
* Create a key for a tab element.
* @param {HTMLElement} el - The tab element.
* @returns {[string, string, string] | null} - The key.
*
*/
function create_key(el) {
let syncId = el.getAttribute("data-sync-id");
let syncGroup = el.getAttribute("data-sync-group");
if (!syncId || !syncGroup) return null;
return [syncGroup, syncId, syncGroup + "--" + syncId];
}
/**
* Initialize the tab selection.
*
*/
function ready() {
// Find all tabs with sync data
/** @type {string[]} */
let groups = [];
document.querySelectorAll(".sd-tab-label").forEach((label) => {
if (label instanceof HTMLElement) {
let data = create_key(label);
if (data) {
let [group, id, key] = data;
// add click event listener
// @ts-ignore
label.onclick = onSDLabelClick;
// store map of key to elements
if (!sd_id_to_elements[key]) {
sd_id_to_elements[key] = [];
}
sd_id_to_elements[key].push(label);
if (groups.indexOf(group) === -1) {
groups.push(group);
// Check if a specific tab has been selected via URL parameter
const tabParam = new URLSearchParams(window.location.search).get(
group
);
if (tabParam) {
console.log(
"sphinx-design: Selecting tab id for group '" +
group +
"' from URL parameter: " +
tabParam
);
window.sessionStorage.setItem(storageKeyPrefix + group, tabParam);
}
}
// Check is a specific tab has been selected previously
let previousId = window.sessionStorage.getItem(
storageKeyPrefix + group
);
if (previousId === id) {
// console.log(
// "sphinx-design: Selecting tab from session storage: " + id
// );
// @ts-ignore
label.previousElementSibling.checked = true;
}
}
}
});
}
/**
* Activate other tabs with the same sync id.
*
* @this {HTMLElement} - The element that was clicked.
*/
function onSDLabelClick() {
let data = create_key(this);
if (!data) return;
let [group, id, key] = data;
for (const label of sd_id_to_elements[key]) {
if (label === this) continue;
// @ts-ignore
label.previousElementSibling.checked = true;
}
window.sessionStorage.setItem(storageKeyPrefix + group, id);
}
document.addEventListener("DOMContentLoaded", ready, false);
_sphinx_design_static/sphinx-design.min.css 0000664 0001750 0001750 00000140307 14744715173 021720 0 ustar jfpiolle jfpiolle .sd-bg-primary{background-color:var(--sd-color-primary) !important}.sd-bg-text-primary{color:var(--sd-color-primary-text) !important}button.sd-bg-primary:focus,button.sd-bg-primary:hover{background-color:var(--sd-color-primary-highlight) !important}a.sd-bg-primary:focus,a.sd-bg-primary:hover{background-color:var(--sd-color-primary-highlight) !important}.sd-bg-secondary{background-color:var(--sd-color-secondary) !important}.sd-bg-text-secondary{color:var(--sd-color-secondary-text) !important}button.sd-bg-secondary:focus,button.sd-bg-secondary:hover{background-color:var(--sd-color-secondary-highlight) !important}a.sd-bg-secondary:focus,a.sd-bg-secondary:hover{background-color:var(--sd-color-secondary-highlight) !important}.sd-bg-success{background-color:var(--sd-color-success) !important}.sd-bg-text-success{color:var(--sd-color-success-text) !important}button.sd-bg-success:focus,button.sd-bg-success:hover{background-color:var(--sd-color-success-highlight) !important}a.sd-bg-success:focus,a.sd-bg-success:hover{background-color:var(--sd-color-success-highlight) !important}.sd-bg-info{background-color:var(--sd-color-info) !important}.sd-bg-text-info{color:var(--sd-color-info-text) !important}button.sd-bg-info:focus,button.sd-bg-info:hover{background-color:var(--sd-color-info-highlight) !important}a.sd-bg-info:focus,a.sd-bg-info:hover{background-color:var(--sd-color-info-highlight) !important}.sd-bg-warning{background-color:var(--sd-color-warning) !important}.sd-bg-text-warning{color:var(--sd-color-warning-text) !important}button.sd-bg-warning:focus,button.sd-bg-warning:hover{background-color:var(--sd-color-warning-highlight) !important}a.sd-bg-warning:focus,a.sd-bg-warning:hover{background-color:var(--sd-color-warning-highlight) !important}.sd-bg-danger{background-color:var(--sd-color-danger) !important}.sd-bg-text-danger{color:var(--sd-color-danger-text) !important}button.sd-bg-danger:focus,button.sd-bg-danger:hover{background-color:var(--sd-color-danger-highlight) !important}a.sd-bg-danger:focus,a.sd-bg-danger:hover{background-color:var(--sd-color-danger-highlight) !important}.sd-bg-light{background-color:var(--sd-color-light) !important}.sd-bg-text-light{color:var(--sd-color-light-text) !important}button.sd-bg-light:focus,button.sd-bg-light:hover{background-color:var(--sd-color-light-highlight) !important}a.sd-bg-light:focus,a.sd-bg-light:hover{background-color:var(--sd-color-light-highlight) !important}.sd-bg-muted{background-color:var(--sd-color-muted) !important}.sd-bg-text-muted{color:var(--sd-color-muted-text) !important}button.sd-bg-muted:focus,button.sd-bg-muted:hover{background-color:var(--sd-color-muted-highlight) !important}a.sd-bg-muted:focus,a.sd-bg-muted:hover{background-color:var(--sd-color-muted-highlight) !important}.sd-bg-dark{background-color:var(--sd-color-dark) !important}.sd-bg-text-dark{color:var(--sd-color-dark-text) !important}button.sd-bg-dark:focus,button.sd-bg-dark:hover{background-color:var(--sd-color-dark-highlight) !important}a.sd-bg-dark:focus,a.sd-bg-dark:hover{background-color:var(--sd-color-dark-highlight) !important}.sd-bg-black{background-color:var(--sd-color-black) !important}.sd-bg-text-black{color:var(--sd-color-black-text) !important}button.sd-bg-black:focus,button.sd-bg-black:hover{background-color:var(--sd-color-black-highlight) !important}a.sd-bg-black:focus,a.sd-bg-black:hover{background-color:var(--sd-color-black-highlight) !important}.sd-bg-white{background-color:var(--sd-color-white) !important}.sd-bg-text-white{color:var(--sd-color-white-text) !important}button.sd-bg-white:focus,button.sd-bg-white:hover{background-color:var(--sd-color-white-highlight) !important}a.sd-bg-white:focus,a.sd-bg-white:hover{background-color:var(--sd-color-white-highlight) !important}.sd-text-primary,.sd-text-primary>p{color:var(--sd-color-primary) !important}a.sd-text-primary:focus,a.sd-text-primary:hover{color:var(--sd-color-primary-highlight) !important}.sd-text-secondary,.sd-text-secondary>p{color:var(--sd-color-secondary) !important}a.sd-text-secondary:focus,a.sd-text-secondary:hover{color:var(--sd-color-secondary-highlight) !important}.sd-text-success,.sd-text-success>p{color:var(--sd-color-success) !important}a.sd-text-success:focus,a.sd-text-success:hover{color:var(--sd-color-success-highlight) !important}.sd-text-info,.sd-text-info>p{color:var(--sd-color-info) !important}a.sd-text-info:focus,a.sd-text-info:hover{color:var(--sd-color-info-highlight) !important}.sd-text-warning,.sd-text-warning>p{color:var(--sd-color-warning) !important}a.sd-text-warning:focus,a.sd-text-warning:hover{color:var(--sd-color-warning-highlight) !important}.sd-text-danger,.sd-text-danger>p{color:var(--sd-color-danger) !important}a.sd-text-danger:focus,a.sd-text-danger:hover{color:var(--sd-color-danger-highlight) !important}.sd-text-light,.sd-text-light>p{color:var(--sd-color-light) !important}a.sd-text-light:focus,a.sd-text-light:hover{color:var(--sd-color-light-highlight) !important}.sd-text-muted,.sd-text-muted>p{color:var(--sd-color-muted) !important}a.sd-text-muted:focus,a.sd-text-muted:hover{color:var(--sd-color-muted-highlight) !important}.sd-text-dark,.sd-text-dark>p{color:var(--sd-color-dark) !important}a.sd-text-dark:focus,a.sd-text-dark:hover{color:var(--sd-color-dark-highlight) !important}.sd-text-black,.sd-text-black>p{color:var(--sd-color-black) !important}a.sd-text-black:focus,a.sd-text-black:hover{color:var(--sd-color-black-highlight) !important}.sd-text-white,.sd-text-white>p{color:var(--sd-color-white) !important}a.sd-text-white:focus,a.sd-text-white:hover{color:var(--sd-color-white-highlight) !important}.sd-outline-primary{border-color:var(--sd-color-primary) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-primary:focus,a.sd-outline-primary:hover{border-color:var(--sd-color-primary-highlight) !important}.sd-outline-secondary{border-color:var(--sd-color-secondary) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-secondary:focus,a.sd-outline-secondary:hover{border-color:var(--sd-color-secondary-highlight) !important}.sd-outline-success{border-color:var(--sd-color-success) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-success:focus,a.sd-outline-success:hover{border-color:var(--sd-color-success-highlight) !important}.sd-outline-info{border-color:var(--sd-color-info) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-info:focus,a.sd-outline-info:hover{border-color:var(--sd-color-info-highlight) !important}.sd-outline-warning{border-color:var(--sd-color-warning) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-warning:focus,a.sd-outline-warning:hover{border-color:var(--sd-color-warning-highlight) !important}.sd-outline-danger{border-color:var(--sd-color-danger) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-danger:focus,a.sd-outline-danger:hover{border-color:var(--sd-color-danger-highlight) !important}.sd-outline-light{border-color:var(--sd-color-light) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-light:focus,a.sd-outline-light:hover{border-color:var(--sd-color-light-highlight) !important}.sd-outline-muted{border-color:var(--sd-color-muted) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-muted:focus,a.sd-outline-muted:hover{border-color:var(--sd-color-muted-highlight) !important}.sd-outline-dark{border-color:var(--sd-color-dark) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-dark:focus,a.sd-outline-dark:hover{border-color:var(--sd-color-dark-highlight) !important}.sd-outline-black{border-color:var(--sd-color-black) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-black:focus,a.sd-outline-black:hover{border-color:var(--sd-color-black-highlight) !important}.sd-outline-white{border-color:var(--sd-color-white) !important;border-style:solid !important;border-width:1px !important}a.sd-outline-white:focus,a.sd-outline-white:hover{border-color:var(--sd-color-white-highlight) !important}.sd-bg-transparent{background-color:transparent !important}.sd-outline-transparent{border-color:transparent !important}.sd-text-transparent{color:transparent !important}.sd-p-0{padding:0 !important}.sd-pt-0,.sd-py-0{padding-top:0 !important}.sd-pr-0,.sd-px-0{padding-right:0 !important}.sd-pb-0,.sd-py-0{padding-bottom:0 !important}.sd-pl-0,.sd-px-0{padding-left:0 !important}.sd-p-1{padding:.25rem !important}.sd-pt-1,.sd-py-1{padding-top:.25rem !important}.sd-pr-1,.sd-px-1{padding-right:.25rem !important}.sd-pb-1,.sd-py-1{padding-bottom:.25rem !important}.sd-pl-1,.sd-px-1{padding-left:.25rem !important}.sd-p-2{padding:.5rem !important}.sd-pt-2,.sd-py-2{padding-top:.5rem !important}.sd-pr-2,.sd-px-2{padding-right:.5rem !important}.sd-pb-2,.sd-py-2{padding-bottom:.5rem !important}.sd-pl-2,.sd-px-2{padding-left:.5rem !important}.sd-p-3{padding:1rem !important}.sd-pt-3,.sd-py-3{padding-top:1rem !important}.sd-pr-3,.sd-px-3{padding-right:1rem !important}.sd-pb-3,.sd-py-3{padding-bottom:1rem !important}.sd-pl-3,.sd-px-3{padding-left:1rem !important}.sd-p-4{padding:1.5rem !important}.sd-pt-4,.sd-py-4{padding-top:1.5rem !important}.sd-pr-4,.sd-px-4{padding-right:1.5rem !important}.sd-pb-4,.sd-py-4{padding-bottom:1.5rem !important}.sd-pl-4,.sd-px-4{padding-left:1.5rem !important}.sd-p-5{padding:3rem !important}.sd-pt-5,.sd-py-5{padding-top:3rem !important}.sd-pr-5,.sd-px-5{padding-right:3rem !important}.sd-pb-5,.sd-py-5{padding-bottom:3rem !important}.sd-pl-5,.sd-px-5{padding-left:3rem !important}.sd-m-auto{margin:auto !important}.sd-mt-auto,.sd-my-auto{margin-top:auto !important}.sd-mr-auto,.sd-mx-auto{margin-right:auto !important}.sd-mb-auto,.sd-my-auto{margin-bottom:auto !important}.sd-ml-auto,.sd-mx-auto{margin-left:auto !important}.sd-m-0{margin:0 !important}.sd-mt-0,.sd-my-0{margin-top:0 !important}.sd-mr-0,.sd-mx-0{margin-right:0 !important}.sd-mb-0,.sd-my-0{margin-bottom:0 !important}.sd-ml-0,.sd-mx-0{margin-left:0 !important}.sd-m-1{margin:.25rem !important}.sd-mt-1,.sd-my-1{margin-top:.25rem !important}.sd-mr-1,.sd-mx-1{margin-right:.25rem !important}.sd-mb-1,.sd-my-1{margin-bottom:.25rem !important}.sd-ml-1,.sd-mx-1{margin-left:.25rem !important}.sd-m-2{margin:.5rem !important}.sd-mt-2,.sd-my-2{margin-top:.5rem !important}.sd-mr-2,.sd-mx-2{margin-right:.5rem !important}.sd-mb-2,.sd-my-2{margin-bottom:.5rem !important}.sd-ml-2,.sd-mx-2{margin-left:.5rem !important}.sd-m-3{margin:1rem !important}.sd-mt-3,.sd-my-3{margin-top:1rem !important}.sd-mr-3,.sd-mx-3{margin-right:1rem !important}.sd-mb-3,.sd-my-3{margin-bottom:1rem !important}.sd-ml-3,.sd-mx-3{margin-left:1rem !important}.sd-m-4{margin:1.5rem !important}.sd-mt-4,.sd-my-4{margin-top:1.5rem !important}.sd-mr-4,.sd-mx-4{margin-right:1.5rem !important}.sd-mb-4,.sd-my-4{margin-bottom:1.5rem !important}.sd-ml-4,.sd-mx-4{margin-left:1.5rem !important}.sd-m-5{margin:3rem !important}.sd-mt-5,.sd-my-5{margin-top:3rem !important}.sd-mr-5,.sd-mx-5{margin-right:3rem !important}.sd-mb-5,.sd-my-5{margin-bottom:3rem !important}.sd-ml-5,.sd-mx-5{margin-left:3rem !important}.sd-w-25{width:25% !important}.sd-w-50{width:50% !important}.sd-w-75{width:75% !important}.sd-w-100{width:100% !important}.sd-w-auto{width:auto !important}.sd-h-25{height:25% !important}.sd-h-50{height:50% !important}.sd-h-75{height:75% !important}.sd-h-100{height:100% !important}.sd-h-auto{height:auto !important}.sd-d-none{display:none !important}.sd-d-inline{display:inline !important}.sd-d-inline-block{display:inline-block !important}.sd-d-block{display:block !important}.sd-d-grid{display:grid !important}.sd-d-flex-row{display:-ms-flexbox !important;display:flex !important;flex-direction:row !important}.sd-d-flex-column{display:-ms-flexbox !important;display:flex !important;flex-direction:column !important}.sd-d-inline-flex{display:-ms-inline-flexbox !important;display:inline-flex !important}@media(min-width: 576px){.sd-d-sm-none{display:none !important}.sd-d-sm-inline{display:inline !important}.sd-d-sm-inline-block{display:inline-block !important}.sd-d-sm-block{display:block !important}.sd-d-sm-grid{display:grid !important}.sd-d-sm-flex{display:-ms-flexbox !important;display:flex !important}.sd-d-sm-inline-flex{display:-ms-inline-flexbox !important;display:inline-flex !important}}@media(min-width: 768px){.sd-d-md-none{display:none !important}.sd-d-md-inline{display:inline !important}.sd-d-md-inline-block{display:inline-block !important}.sd-d-md-block{display:block !important}.sd-d-md-grid{display:grid !important}.sd-d-md-flex{display:-ms-flexbox !important;display:flex !important}.sd-d-md-inline-flex{display:-ms-inline-flexbox !important;display:inline-flex !important}}@media(min-width: 992px){.sd-d-lg-none{display:none !important}.sd-d-lg-inline{display:inline !important}.sd-d-lg-inline-block{display:inline-block !important}.sd-d-lg-block{display:block !important}.sd-d-lg-grid{display:grid !important}.sd-d-lg-flex{display:-ms-flexbox !important;display:flex !important}.sd-d-lg-inline-flex{display:-ms-inline-flexbox !important;display:inline-flex !important}}@media(min-width: 1200px){.sd-d-xl-none{display:none !important}.sd-d-xl-inline{display:inline !important}.sd-d-xl-inline-block{display:inline-block !important}.sd-d-xl-block{display:block !important}.sd-d-xl-grid{display:grid !important}.sd-d-xl-flex{display:-ms-flexbox !important;display:flex !important}.sd-d-xl-inline-flex{display:-ms-inline-flexbox !important;display:inline-flex !important}}.sd-align-major-start{justify-content:flex-start !important}.sd-align-major-end{justify-content:flex-end !important}.sd-align-major-center{justify-content:center !important}.sd-align-major-justify{justify-content:space-between !important}.sd-align-major-spaced{justify-content:space-evenly !important}.sd-align-minor-start{align-items:flex-start !important}.sd-align-minor-end{align-items:flex-end !important}.sd-align-minor-center{align-items:center !important}.sd-align-minor-stretch{align-items:stretch !important}.sd-text-justify{text-align:justify !important}.sd-text-left{text-align:left !important}.sd-text-right{text-align:right !important}.sd-text-center{text-align:center !important}.sd-font-weight-light{font-weight:300 !important}.sd-font-weight-lighter{font-weight:lighter !important}.sd-font-weight-normal{font-weight:400 !important}.sd-font-weight-bold{font-weight:700 !important}.sd-font-weight-bolder{font-weight:bolder !important}.sd-font-italic{font-style:italic !important}.sd-text-decoration-none{text-decoration:none !important}.sd-text-lowercase{text-transform:lowercase !important}.sd-text-uppercase{text-transform:uppercase !important}.sd-text-capitalize{text-transform:capitalize !important}.sd-text-wrap{white-space:normal !important}.sd-text-nowrap{white-space:nowrap !important}.sd-text-truncate{overflow:hidden;text-overflow:ellipsis;white-space:nowrap}.sd-fs-1,.sd-fs-1>p{font-size:calc(1.375rem + 1.5vw) !important;line-height:unset !important}.sd-fs-2,.sd-fs-2>p{font-size:calc(1.325rem + 0.9vw) !important;line-height:unset !important}.sd-fs-3,.sd-fs-3>p{font-size:calc(1.3rem + 0.6vw) !important;line-height:unset !important}.sd-fs-4,.sd-fs-4>p{font-size:calc(1.275rem + 0.3vw) !important;line-height:unset !important}.sd-fs-5,.sd-fs-5>p{font-size:1.25rem !important;line-height:unset !important}.sd-fs-6,.sd-fs-6>p{font-size:1rem !important;line-height:unset !important}.sd-border-0{border:0 solid !important}.sd-border-top-0{border-top:0 solid !important}.sd-border-bottom-0{border-bottom:0 solid !important}.sd-border-right-0{border-right:0 solid !important}.sd-border-left-0{border-left:0 solid !important}.sd-border-1{border:1px solid !important}.sd-border-top-1{border-top:1px solid !important}.sd-border-bottom-1{border-bottom:1px solid !important}.sd-border-right-1{border-right:1px solid !important}.sd-border-left-1{border-left:1px solid !important}.sd-border-2{border:2px solid !important}.sd-border-top-2{border-top:2px solid !important}.sd-border-bottom-2{border-bottom:2px solid !important}.sd-border-right-2{border-right:2px solid !important}.sd-border-left-2{border-left:2px solid !important}.sd-border-3{border:3px solid !important}.sd-border-top-3{border-top:3px solid !important}.sd-border-bottom-3{border-bottom:3px solid !important}.sd-border-right-3{border-right:3px solid !important}.sd-border-left-3{border-left:3px solid !important}.sd-border-4{border:4px solid !important}.sd-border-top-4{border-top:4px solid !important}.sd-border-bottom-4{border-bottom:4px solid !important}.sd-border-right-4{border-right:4px solid !important}.sd-border-left-4{border-left:4px solid !important}.sd-border-5{border:5px solid !important}.sd-border-top-5{border-top:5px solid !important}.sd-border-bottom-5{border-bottom:5px solid !important}.sd-border-right-5{border-right:5px solid !important}.sd-border-left-5{border-left:5px solid !important}.sd-rounded-0{border-radius:0 !important}.sd-rounded-1{border-radius:.2rem !important}.sd-rounded-2{border-radius:.3rem !important}.sd-rounded-3{border-radius:.5rem !important}.sd-rounded-pill{border-radius:50rem !important}.sd-rounded-circle{border-radius:50% !important}.shadow-none{box-shadow:none !important}.sd-shadow-sm{box-shadow:0 .125rem .25rem var(--sd-color-shadow) !important}.sd-shadow-md{box-shadow:0 .5rem 1rem var(--sd-color-shadow) !important}.sd-shadow-lg{box-shadow:0 1rem 3rem var(--sd-color-shadow) !important}@keyframes sd-slide-from-left{0%{transform:translateX(-100%)}100%{transform:translateX(0)}}@keyframes sd-slide-from-right{0%{transform:translateX(200%)}100%{transform:translateX(0)}}@keyframes sd-grow100{0%{transform:scale(0);opacity:.5}100%{transform:scale(1);opacity:1}}@keyframes sd-grow50{0%{transform:scale(0.5);opacity:.5}100%{transform:scale(1);opacity:1}}@keyframes sd-grow50-rot20{0%{transform:scale(0.5) rotateZ(-20deg);opacity:.5}75%{transform:scale(1) rotateZ(5deg);opacity:1}95%{transform:scale(1) rotateZ(-1deg);opacity:1}100%{transform:scale(1) rotateZ(0);opacity:1}}.sd-animate-slide-from-left{animation:1s ease-out 0s 1 normal none running sd-slide-from-left}.sd-animate-slide-from-right{animation:1s ease-out 0s 1 normal none running sd-slide-from-right}.sd-animate-grow100{animation:1s ease-out 0s 1 normal none running sd-grow100}.sd-animate-grow50{animation:1s ease-out 0s 1 normal none running sd-grow50}.sd-animate-grow50-rot20{animation:1s ease-out 0s 1 normal none running sd-grow50-rot20}.sd-badge{display:inline-block;padding:.35em .65em;font-size:.75em;font-weight:700;line-height:1;text-align:center;white-space:nowrap;vertical-align:baseline;border-radius:.25rem}.sd-badge:empty{display:none}a.sd-badge{text-decoration:none}.sd-btn .sd-badge{position:relative;top:-1px}.sd-btn{background-color:transparent;border:1px solid transparent;border-radius:.25rem;cursor:pointer;display:inline-block;font-weight:400;font-size:1rem;line-height:1.5;padding:.375rem .75rem;text-align:center;text-decoration:none;transition:color .15s ease-in-out,background-color .15s ease-in-out,border-color .15s ease-in-out,box-shadow .15s ease-in-out;vertical-align:middle;user-select:none;-moz-user-select:none;-ms-user-select:none;-webkit-user-select:none}.sd-btn:hover{text-decoration:none}@media(prefers-reduced-motion: reduce){.sd-btn{transition:none}}.sd-btn-primary,.sd-btn-outline-primary:hover,.sd-btn-outline-primary:focus{color:var(--sd-color-primary-text) !important;background-color:var(--sd-color-primary) !important;border-color:var(--sd-color-primary) !important;border-width:1px !important;border-style:solid !important}.sd-btn-primary:hover,.sd-btn-primary:focus{color:var(--sd-color-primary-text) !important;background-color:var(--sd-color-primary-highlight) !important;border-color:var(--sd-color-primary-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-primary{color:var(--sd-color-primary) !important;border-color:var(--sd-color-primary) !important;border-width:1px !important;border-style:solid !important}.sd-btn-secondary,.sd-btn-outline-secondary:hover,.sd-btn-outline-secondary:focus{color:var(--sd-color-secondary-text) !important;background-color:var(--sd-color-secondary) !important;border-color:var(--sd-color-secondary) !important;border-width:1px !important;border-style:solid !important}.sd-btn-secondary:hover,.sd-btn-secondary:focus{color:var(--sd-color-secondary-text) !important;background-color:var(--sd-color-secondary-highlight) !important;border-color:var(--sd-color-secondary-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-secondary{color:var(--sd-color-secondary) !important;border-color:var(--sd-color-secondary) !important;border-width:1px !important;border-style:solid !important}.sd-btn-success,.sd-btn-outline-success:hover,.sd-btn-outline-success:focus{color:var(--sd-color-success-text) !important;background-color:var(--sd-color-success) !important;border-color:var(--sd-color-success) !important;border-width:1px !important;border-style:solid !important}.sd-btn-success:hover,.sd-btn-success:focus{color:var(--sd-color-success-text) !important;background-color:var(--sd-color-success-highlight) !important;border-color:var(--sd-color-success-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-success{color:var(--sd-color-success) !important;border-color:var(--sd-color-success) !important;border-width:1px !important;border-style:solid !important}.sd-btn-info,.sd-btn-outline-info:hover,.sd-btn-outline-info:focus{color:var(--sd-color-info-text) !important;background-color:var(--sd-color-info) !important;border-color:var(--sd-color-info) !important;border-width:1px !important;border-style:solid !important}.sd-btn-info:hover,.sd-btn-info:focus{color:var(--sd-color-info-text) !important;background-color:var(--sd-color-info-highlight) !important;border-color:var(--sd-color-info-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-info{color:var(--sd-color-info) !important;border-color:var(--sd-color-info) !important;border-width:1px !important;border-style:solid !important}.sd-btn-warning,.sd-btn-outline-warning:hover,.sd-btn-outline-warning:focus{color:var(--sd-color-warning-text) !important;background-color:var(--sd-color-warning) !important;border-color:var(--sd-color-warning) !important;border-width:1px !important;border-style:solid !important}.sd-btn-warning:hover,.sd-btn-warning:focus{color:var(--sd-color-warning-text) !important;background-color:var(--sd-color-warning-highlight) !important;border-color:var(--sd-color-warning-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-warning{color:var(--sd-color-warning) !important;border-color:var(--sd-color-warning) !important;border-width:1px !important;border-style:solid !important}.sd-btn-danger,.sd-btn-outline-danger:hover,.sd-btn-outline-danger:focus{color:var(--sd-color-danger-text) !important;background-color:var(--sd-color-danger) !important;border-color:var(--sd-color-danger) !important;border-width:1px !important;border-style:solid !important}.sd-btn-danger:hover,.sd-btn-danger:focus{color:var(--sd-color-danger-text) !important;background-color:var(--sd-color-danger-highlight) !important;border-color:var(--sd-color-danger-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-danger{color:var(--sd-color-danger) !important;border-color:var(--sd-color-danger) !important;border-width:1px !important;border-style:solid !important}.sd-btn-light,.sd-btn-outline-light:hover,.sd-btn-outline-light:focus{color:var(--sd-color-light-text) !important;background-color:var(--sd-color-light) !important;border-color:var(--sd-color-light) !important;border-width:1px !important;border-style:solid !important}.sd-btn-light:hover,.sd-btn-light:focus{color:var(--sd-color-light-text) !important;background-color:var(--sd-color-light-highlight) !important;border-color:var(--sd-color-light-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-light{color:var(--sd-color-light) !important;border-color:var(--sd-color-light) !important;border-width:1px !important;border-style:solid !important}.sd-btn-muted,.sd-btn-outline-muted:hover,.sd-btn-outline-muted:focus{color:var(--sd-color-muted-text) !important;background-color:var(--sd-color-muted) !important;border-color:var(--sd-color-muted) !important;border-width:1px !important;border-style:solid !important}.sd-btn-muted:hover,.sd-btn-muted:focus{color:var(--sd-color-muted-text) !important;background-color:var(--sd-color-muted-highlight) !important;border-color:var(--sd-color-muted-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-muted{color:var(--sd-color-muted) !important;border-color:var(--sd-color-muted) !important;border-width:1px !important;border-style:solid !important}.sd-btn-dark,.sd-btn-outline-dark:hover,.sd-btn-outline-dark:focus{color:var(--sd-color-dark-text) !important;background-color:var(--sd-color-dark) !important;border-color:var(--sd-color-dark) !important;border-width:1px !important;border-style:solid !important}.sd-btn-dark:hover,.sd-btn-dark:focus{color:var(--sd-color-dark-text) !important;background-color:var(--sd-color-dark-highlight) !important;border-color:var(--sd-color-dark-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-dark{color:var(--sd-color-dark) !important;border-color:var(--sd-color-dark) !important;border-width:1px !important;border-style:solid !important}.sd-btn-black,.sd-btn-outline-black:hover,.sd-btn-outline-black:focus{color:var(--sd-color-black-text) !important;background-color:var(--sd-color-black) !important;border-color:var(--sd-color-black) !important;border-width:1px !important;border-style:solid !important}.sd-btn-black:hover,.sd-btn-black:focus{color:var(--sd-color-black-text) !important;background-color:var(--sd-color-black-highlight) !important;border-color:var(--sd-color-black-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-black{color:var(--sd-color-black) !important;border-color:var(--sd-color-black) !important;border-width:1px !important;border-style:solid !important}.sd-btn-white,.sd-btn-outline-white:hover,.sd-btn-outline-white:focus{color:var(--sd-color-white-text) !important;background-color:var(--sd-color-white) !important;border-color:var(--sd-color-white) !important;border-width:1px !important;border-style:solid !important}.sd-btn-white:hover,.sd-btn-white:focus{color:var(--sd-color-white-text) !important;background-color:var(--sd-color-white-highlight) !important;border-color:var(--sd-color-white-highlight) !important;border-width:1px !important;border-style:solid !important}.sd-btn-outline-white{color:var(--sd-color-white) !important;border-color:var(--sd-color-white) !important;border-width:1px !important;border-style:solid !important}.sd-stretched-link::after{position:absolute;top:0;right:0;bottom:0;left:0;z-index:1;content:""}.sd-hide-link-text{font-size:0}.sd-octicon,.sd-material-icon{display:inline-block;fill:currentColor;vertical-align:middle}.sd-avatar-xs{border-radius:50%;object-fit:cover;object-position:center;width:1rem;height:1rem}.sd-avatar-sm{border-radius:50%;object-fit:cover;object-position:center;width:3rem;height:3rem}.sd-avatar-md{border-radius:50%;object-fit:cover;object-position:center;width:5rem;height:5rem}.sd-avatar-lg{border-radius:50%;object-fit:cover;object-position:center;width:7rem;height:7rem}.sd-avatar-xl{border-radius:50%;object-fit:cover;object-position:center;width:10rem;height:10rem}.sd-avatar-inherit{border-radius:50%;object-fit:cover;object-position:center;width:inherit;height:inherit}.sd-avatar-initial{border-radius:50%;object-fit:cover;object-position:center;width:initial;height:initial}.sd-card{background-clip:border-box;background-color:var(--sd-color-card-background);border:1px solid var(--sd-color-card-border);border-radius:.25rem;color:var(--sd-color-card-text);display:-ms-flexbox;display:flex;-ms-flex-direction:column;flex-direction:column;min-width:0;position:relative;word-wrap:break-word}.sd-card>hr{margin-left:0;margin-right:0}.sd-card-hover:hover{border-color:var(--sd-color-card-border-hover);transform:scale(1.01)}.sd-card-body{-ms-flex:1 1 auto;flex:1 1 auto;padding:1rem 1rem}.sd-card-title{margin-bottom:.5rem}.sd-card-subtitle{margin-top:-0.25rem;margin-bottom:0}.sd-card-text:last-child{margin-bottom:0}.sd-card-link:hover{text-decoration:none}.sd-card-link+.card-link{margin-left:1rem}.sd-card-header{padding:.5rem 1rem;margin-bottom:0;background-color:var(--sd-color-card-header);border-bottom:1px solid var(--sd-color-card-border)}.sd-card-header:first-child{border-radius:calc(0.25rem - 1px) calc(0.25rem - 1px) 0 0}.sd-card-footer{padding:.5rem 1rem;background-color:var(--sd-color-card-footer);border-top:1px solid var(--sd-color-card-border)}.sd-card-footer:last-child{border-radius:0 0 calc(0.25rem - 1px) calc(0.25rem - 1px)}.sd-card-header-tabs{margin-right:-0.5rem;margin-bottom:-0.5rem;margin-left:-0.5rem;border-bottom:0}.sd-card-header-pills{margin-right:-0.5rem;margin-left:-0.5rem}.sd-card-img-overlay{position:absolute;top:0;right:0;bottom:0;left:0;padding:1rem;border-radius:calc(0.25rem - 1px)}.sd-card-img,.sd-card-img-bottom,.sd-card-img-top{width:100%}.sd-card-img,.sd-card-img-top{border-top-left-radius:calc(0.25rem - 1px);border-top-right-radius:calc(0.25rem - 1px)}.sd-card-img,.sd-card-img-bottom{border-bottom-left-radius:calc(0.25rem - 1px);border-bottom-right-radius:calc(0.25rem - 1px)}.sd-cards-carousel{width:100%;display:flex;flex-wrap:nowrap;-ms-flex-direction:row;flex-direction:row;overflow-x:hidden;scroll-snap-type:x mandatory}.sd-cards-carousel.sd-show-scrollbar{overflow-x:auto}.sd-cards-carousel:hover,.sd-cards-carousel:focus{overflow-x:auto}.sd-cards-carousel>.sd-card{flex-shrink:0;scroll-snap-align:start}.sd-cards-carousel>.sd-card:not(:last-child){margin-right:3px}.sd-card-cols-1>.sd-card{width:90%}.sd-card-cols-2>.sd-card{width:45%}.sd-card-cols-3>.sd-card{width:30%}.sd-card-cols-4>.sd-card{width:22.5%}.sd-card-cols-5>.sd-card{width:18%}.sd-card-cols-6>.sd-card{width:15%}.sd-card-cols-7>.sd-card{width:12.8571428571%}.sd-card-cols-8>.sd-card{width:11.25%}.sd-card-cols-9>.sd-card{width:10%}.sd-card-cols-10>.sd-card{width:9%}.sd-card-cols-11>.sd-card{width:8.1818181818%}.sd-card-cols-12>.sd-card{width:7.5%}.sd-container,.sd-container-fluid,.sd-container-lg,.sd-container-md,.sd-container-sm,.sd-container-xl{margin-left:auto;margin-right:auto;padding-left:var(--sd-gutter-x, 0.75rem);padding-right:var(--sd-gutter-x, 0.75rem);width:100%}@media(min-width: 576px){.sd-container-sm,.sd-container{max-width:540px}}@media(min-width: 768px){.sd-container-md,.sd-container-sm,.sd-container{max-width:720px}}@media(min-width: 992px){.sd-container-lg,.sd-container-md,.sd-container-sm,.sd-container{max-width:960px}}@media(min-width: 1200px){.sd-container-xl,.sd-container-lg,.sd-container-md,.sd-container-sm,.sd-container{max-width:1140px}}.sd-row{--sd-gutter-x: 1.5rem;--sd-gutter-y: 0;display:-ms-flexbox;display:flex;-ms-flex-wrap:wrap;flex-wrap:wrap;margin-top:calc(var(--sd-gutter-y) * -1);margin-right:calc(var(--sd-gutter-x) * -0.5);margin-left:calc(var(--sd-gutter-x) * -0.5)}.sd-row>*{box-sizing:border-box;flex-shrink:0;width:100%;max-width:100%;padding-right:calc(var(--sd-gutter-x) * 0.5);padding-left:calc(var(--sd-gutter-x) * 0.5);margin-top:var(--sd-gutter-y)}.sd-col{flex:1 0 0%;-ms-flex:1 0 0%}.sd-row-cols-auto>*{flex:0 0 auto;width:auto}.sd-row-cols-1>*{flex:0 0 auto;-ms-flex:0 0 auto;width:100%}.sd-row-cols-2>*{flex:0 0 auto;-ms-flex:0 0 auto;width:50%}.sd-row-cols-3>*{flex:0 0 auto;-ms-flex:0 0 auto;width:33.3333333333%}.sd-row-cols-4>*{flex:0 0 auto;-ms-flex:0 0 auto;width:25%}.sd-row-cols-5>*{flex:0 0 auto;-ms-flex:0 0 auto;width:20%}.sd-row-cols-6>*{flex:0 0 auto;-ms-flex:0 0 auto;width:16.6666666667%}.sd-row-cols-7>*{flex:0 0 auto;-ms-flex:0 0 auto;width:14.2857142857%}.sd-row-cols-8>*{flex:0 0 auto;-ms-flex:0 0 auto;width:12.5%}.sd-row-cols-9>*{flex:0 0 auto;-ms-flex:0 0 auto;width:11.1111111111%}.sd-row-cols-10>*{flex:0 0 auto;-ms-flex:0 0 auto;width:10%}.sd-row-cols-11>*{flex:0 0 auto;-ms-flex:0 0 auto;width:9.0909090909%}.sd-row-cols-12>*{flex:0 0 auto;-ms-flex:0 0 auto;width:8.3333333333%}@media(min-width: 576px){.sd-col-sm{flex:1 0 0%;-ms-flex:1 0 0%}.sd-row-cols-sm-auto{flex:1 0 auto;-ms-flex:1 0 auto;width:100%}.sd-row-cols-sm-1>*{flex:0 0 auto;-ms-flex:0 0 auto;width:100%}.sd-row-cols-sm-2>*{flex:0 0 auto;-ms-flex:0 0 auto;width:50%}.sd-row-cols-sm-3>*{flex:0 0 auto;-ms-flex:0 0 auto;width:33.3333333333%}.sd-row-cols-sm-4>*{flex:0 0 auto;-ms-flex:0 0 auto;width:25%}.sd-row-cols-sm-5>*{flex:0 0 auto;-ms-flex:0 0 auto;width:20%}.sd-row-cols-sm-6>*{flex:0 0 auto;-ms-flex:0 0 auto;width:16.6666666667%}.sd-row-cols-sm-7>*{flex:0 0 auto;-ms-flex:0 0 auto;width:14.2857142857%}.sd-row-cols-sm-8>*{flex:0 0 auto;-ms-flex:0 0 auto;width:12.5%}.sd-row-cols-sm-9>*{flex:0 0 auto;-ms-flex:0 0 auto;width:11.1111111111%}.sd-row-cols-sm-10>*{flex:0 0 auto;-ms-flex:0 0 auto;width:10%}.sd-row-cols-sm-11>*{flex:0 0 auto;-ms-flex:0 0 auto;width:9.0909090909%}.sd-row-cols-sm-12>*{flex:0 0 auto;-ms-flex:0 0 auto;width:8.3333333333%}}@media(min-width: 768px){.sd-col-md{flex:1 0 0%;-ms-flex:1 0 0%}.sd-row-cols-md-auto{flex:1 0 auto;-ms-flex:1 0 auto;width:100%}.sd-row-cols-md-1>*{flex:0 0 auto;-ms-flex:0 0 auto;width:100%}.sd-row-cols-md-2>*{flex:0 0 auto;-ms-flex:0 0 auto;width:50%}.sd-row-cols-md-3>*{flex:0 0 auto;-ms-flex:0 0 auto;width:33.3333333333%}.sd-row-cols-md-4>*{flex:0 0 auto;-ms-flex:0 0 auto;width:25%}.sd-row-cols-md-5>*{flex:0 0 auto;-ms-flex:0 0 auto;width:20%}.sd-row-cols-md-6>*{flex:0 0 auto;-ms-flex:0 0 auto;width:16.6666666667%}.sd-row-cols-md-7>*{flex:0 0 auto;-ms-flex:0 0 auto;width:14.2857142857%}.sd-row-cols-md-8>*{flex:0 0 auto;-ms-flex:0 0 auto;width:12.5%}.sd-row-cols-md-9>*{flex:0 0 auto;-ms-flex:0 0 auto;width:11.1111111111%}.sd-row-cols-md-10>*{flex:0 0 auto;-ms-flex:0 0 auto;width:10%}.sd-row-cols-md-11>*{flex:0 0 auto;-ms-flex:0 0 auto;width:9.0909090909%}.sd-row-cols-md-12>*{flex:0 0 auto;-ms-flex:0 0 auto;width:8.3333333333%}}@media(min-width: 992px){.sd-col-lg{flex:1 0 0%;-ms-flex:1 0 0%}.sd-row-cols-lg-auto{flex:1 0 auto;-ms-flex:1 0 auto;width:100%}.sd-row-cols-lg-1>*{flex:0 0 auto;-ms-flex:0 0 auto;width:100%}.sd-row-cols-lg-2>*{flex:0 0 auto;-ms-flex:0 0 auto;width:50%}.sd-row-cols-lg-3>*{flex:0 0 auto;-ms-flex:0 0 auto;width:33.3333333333%}.sd-row-cols-lg-4>*{flex:0 0 auto;-ms-flex:0 0 auto;width:25%}.sd-row-cols-lg-5>*{flex:0 0 auto;-ms-flex:0 0 auto;width:20%}.sd-row-cols-lg-6>*{flex:0 0 auto;-ms-flex:0 0 auto;width:16.6666666667%}.sd-row-cols-lg-7>*{flex:0 0 auto;-ms-flex:0 0 auto;width:14.2857142857%}.sd-row-cols-lg-8>*{flex:0 0 auto;-ms-flex:0 0 auto;width:12.5%}.sd-row-cols-lg-9>*{flex:0 0 auto;-ms-flex:0 0 auto;width:11.1111111111%}.sd-row-cols-lg-10>*{flex:0 0 auto;-ms-flex:0 0 auto;width:10%}.sd-row-cols-lg-11>*{flex:0 0 auto;-ms-flex:0 0 auto;width:9.0909090909%}.sd-row-cols-lg-12>*{flex:0 0 auto;-ms-flex:0 0 auto;width:8.3333333333%}}@media(min-width: 1200px){.sd-col-xl{flex:1 0 0%;-ms-flex:1 0 0%}.sd-row-cols-xl-auto{flex:1 0 auto;-ms-flex:1 0 auto;width:100%}.sd-row-cols-xl-1>*{flex:0 0 auto;-ms-flex:0 0 auto;width:100%}.sd-row-cols-xl-2>*{flex:0 0 auto;-ms-flex:0 0 auto;width:50%}.sd-row-cols-xl-3>*{flex:0 0 auto;-ms-flex:0 0 auto;width:33.3333333333%}.sd-row-cols-xl-4>*{flex:0 0 auto;-ms-flex:0 0 auto;width:25%}.sd-row-cols-xl-5>*{flex:0 0 auto;-ms-flex:0 0 auto;width:20%}.sd-row-cols-xl-6>*{flex:0 0 auto;-ms-flex:0 0 auto;width:16.6666666667%}.sd-row-cols-xl-7>*{flex:0 0 auto;-ms-flex:0 0 auto;width:14.2857142857%}.sd-row-cols-xl-8>*{flex:0 0 auto;-ms-flex:0 0 auto;width:12.5%}.sd-row-cols-xl-9>*{flex:0 0 auto;-ms-flex:0 0 auto;width:11.1111111111%}.sd-row-cols-xl-10>*{flex:0 0 auto;-ms-flex:0 0 auto;width:10%}.sd-row-cols-xl-11>*{flex:0 0 auto;-ms-flex:0 0 auto;width:9.0909090909%}.sd-row-cols-xl-12>*{flex:0 0 auto;-ms-flex:0 0 auto;width:8.3333333333%}}.sd-col-auto{flex:0 0 auto;-ms-flex:0 0 auto;width:auto}.sd-col-1{flex:0 0 auto;-ms-flex:0 0 auto;width:8.3333333333%}.sd-col-2{flex:0 0 auto;-ms-flex:0 0 auto;width:16.6666666667%}.sd-col-3{flex:0 0 auto;-ms-flex:0 0 auto;width:25%}.sd-col-4{flex:0 0 auto;-ms-flex:0 0 auto;width:33.3333333333%}.sd-col-5{flex:0 0 auto;-ms-flex:0 0 auto;width:41.6666666667%}.sd-col-6{flex:0 0 auto;-ms-flex:0 0 auto;width:50%}.sd-col-7{flex:0 0 auto;-ms-flex:0 0 auto;width:58.3333333333%}.sd-col-8{flex:0 0 auto;-ms-flex:0 0 auto;width:66.6666666667%}.sd-col-9{flex:0 0 auto;-ms-flex:0 0 auto;width:75%}.sd-col-10{flex:0 0 auto;-ms-flex:0 0 auto;width:83.3333333333%}.sd-col-11{flex:0 0 auto;-ms-flex:0 0 auto;width:91.6666666667%}.sd-col-12{flex:0 0 auto;-ms-flex:0 0 auto;width:100%}.sd-g-0,.sd-gy-0{--sd-gutter-y: 0}.sd-g-0,.sd-gx-0{--sd-gutter-x: 0}.sd-g-1,.sd-gy-1{--sd-gutter-y: 0.25rem}.sd-g-1,.sd-gx-1{--sd-gutter-x: 0.25rem}.sd-g-2,.sd-gy-2{--sd-gutter-y: 0.5rem}.sd-g-2,.sd-gx-2{--sd-gutter-x: 0.5rem}.sd-g-3,.sd-gy-3{--sd-gutter-y: 1rem}.sd-g-3,.sd-gx-3{--sd-gutter-x: 1rem}.sd-g-4,.sd-gy-4{--sd-gutter-y: 1.5rem}.sd-g-4,.sd-gx-4{--sd-gutter-x: 1.5rem}.sd-g-5,.sd-gy-5{--sd-gutter-y: 3rem}.sd-g-5,.sd-gx-5{--sd-gutter-x: 3rem}@media(min-width: 576px){.sd-col-sm-auto{-ms-flex:0 0 auto;flex:0 0 auto;width:auto}.sd-col-sm-1{-ms-flex:0 0 auto;flex:0 0 auto;width:8.3333333333%}.sd-col-sm-2{-ms-flex:0 0 auto;flex:0 0 auto;width:16.6666666667%}.sd-col-sm-3{-ms-flex:0 0 auto;flex:0 0 auto;width:25%}.sd-col-sm-4{-ms-flex:0 0 auto;flex:0 0 auto;width:33.3333333333%}.sd-col-sm-5{-ms-flex:0 0 auto;flex:0 0 auto;width:41.6666666667%}.sd-col-sm-6{-ms-flex:0 0 auto;flex:0 0 auto;width:50%}.sd-col-sm-7{-ms-flex:0 0 auto;flex:0 0 auto;width:58.3333333333%}.sd-col-sm-8{-ms-flex:0 0 auto;flex:0 0 auto;width:66.6666666667%}.sd-col-sm-9{-ms-flex:0 0 auto;flex:0 0 auto;width:75%}.sd-col-sm-10{-ms-flex:0 0 auto;flex:0 0 auto;width:83.3333333333%}.sd-col-sm-11{-ms-flex:0 0 auto;flex:0 0 auto;width:91.6666666667%}.sd-col-sm-12{-ms-flex:0 0 auto;flex:0 0 auto;width:100%}.sd-g-sm-0,.sd-gy-sm-0{--sd-gutter-y: 0}.sd-g-sm-0,.sd-gx-sm-0{--sd-gutter-x: 0}.sd-g-sm-1,.sd-gy-sm-1{--sd-gutter-y: 0.25rem}.sd-g-sm-1,.sd-gx-sm-1{--sd-gutter-x: 0.25rem}.sd-g-sm-2,.sd-gy-sm-2{--sd-gutter-y: 0.5rem}.sd-g-sm-2,.sd-gx-sm-2{--sd-gutter-x: 0.5rem}.sd-g-sm-3,.sd-gy-sm-3{--sd-gutter-y: 1rem}.sd-g-sm-3,.sd-gx-sm-3{--sd-gutter-x: 1rem}.sd-g-sm-4,.sd-gy-sm-4{--sd-gutter-y: 1.5rem}.sd-g-sm-4,.sd-gx-sm-4{--sd-gutter-x: 1.5rem}.sd-g-sm-5,.sd-gy-sm-5{--sd-gutter-y: 3rem}.sd-g-sm-5,.sd-gx-sm-5{--sd-gutter-x: 3rem}}@media(min-width: 768px){.sd-col-md-auto{-ms-flex:0 0 auto;flex:0 0 auto;width:auto}.sd-col-md-1{-ms-flex:0 0 auto;flex:0 0 auto;width:8.3333333333%}.sd-col-md-2{-ms-flex:0 0 auto;flex:0 0 auto;width:16.6666666667%}.sd-col-md-3{-ms-flex:0 0 auto;flex:0 0 auto;width:25%}.sd-col-md-4{-ms-flex:0 0 auto;flex:0 0 auto;width:33.3333333333%}.sd-col-md-5{-ms-flex:0 0 auto;flex:0 0 auto;width:41.6666666667%}.sd-col-md-6{-ms-flex:0 0 auto;flex:0 0 auto;width:50%}.sd-col-md-7{-ms-flex:0 0 auto;flex:0 0 auto;width:58.3333333333%}.sd-col-md-8{-ms-flex:0 0 auto;flex:0 0 auto;width:66.6666666667%}.sd-col-md-9{-ms-flex:0 0 auto;flex:0 0 auto;width:75%}.sd-col-md-10{-ms-flex:0 0 auto;flex:0 0 auto;width:83.3333333333%}.sd-col-md-11{-ms-flex:0 0 auto;flex:0 0 auto;width:91.6666666667%}.sd-col-md-12{-ms-flex:0 0 auto;flex:0 0 auto;width:100%}.sd-g-md-0,.sd-gy-md-0{--sd-gutter-y: 0}.sd-g-md-0,.sd-gx-md-0{--sd-gutter-x: 0}.sd-g-md-1,.sd-gy-md-1{--sd-gutter-y: 0.25rem}.sd-g-md-1,.sd-gx-md-1{--sd-gutter-x: 0.25rem}.sd-g-md-2,.sd-gy-md-2{--sd-gutter-y: 0.5rem}.sd-g-md-2,.sd-gx-md-2{--sd-gutter-x: 0.5rem}.sd-g-md-3,.sd-gy-md-3{--sd-gutter-y: 1rem}.sd-g-md-3,.sd-gx-md-3{--sd-gutter-x: 1rem}.sd-g-md-4,.sd-gy-md-4{--sd-gutter-y: 1.5rem}.sd-g-md-4,.sd-gx-md-4{--sd-gutter-x: 1.5rem}.sd-g-md-5,.sd-gy-md-5{--sd-gutter-y: 3rem}.sd-g-md-5,.sd-gx-md-5{--sd-gutter-x: 3rem}}@media(min-width: 992px){.sd-col-lg-auto{-ms-flex:0 0 auto;flex:0 0 auto;width:auto}.sd-col-lg-1{-ms-flex:0 0 auto;flex:0 0 auto;width:8.3333333333%}.sd-col-lg-2{-ms-flex:0 0 auto;flex:0 0 auto;width:16.6666666667%}.sd-col-lg-3{-ms-flex:0 0 auto;flex:0 0 auto;width:25%}.sd-col-lg-4{-ms-flex:0 0 auto;flex:0 0 auto;width:33.3333333333%}.sd-col-lg-5{-ms-flex:0 0 auto;flex:0 0 auto;width:41.6666666667%}.sd-col-lg-6{-ms-flex:0 0 auto;flex:0 0 auto;width:50%}.sd-col-lg-7{-ms-flex:0 0 auto;flex:0 0 auto;width:58.3333333333%}.sd-col-lg-8{-ms-flex:0 0 auto;flex:0 0 auto;width:66.6666666667%}.sd-col-lg-9{-ms-flex:0 0 auto;flex:0 0 auto;width:75%}.sd-col-lg-10{-ms-flex:0 0 auto;flex:0 0 auto;width:83.3333333333%}.sd-col-lg-11{-ms-flex:0 0 auto;flex:0 0 auto;width:91.6666666667%}.sd-col-lg-12{-ms-flex:0 0 auto;flex:0 0 auto;width:100%}.sd-g-lg-0,.sd-gy-lg-0{--sd-gutter-y: 0}.sd-g-lg-0,.sd-gx-lg-0{--sd-gutter-x: 0}.sd-g-lg-1,.sd-gy-lg-1{--sd-gutter-y: 0.25rem}.sd-g-lg-1,.sd-gx-lg-1{--sd-gutter-x: 0.25rem}.sd-g-lg-2,.sd-gy-lg-2{--sd-gutter-y: 0.5rem}.sd-g-lg-2,.sd-gx-lg-2{--sd-gutter-x: 0.5rem}.sd-g-lg-3,.sd-gy-lg-3{--sd-gutter-y: 1rem}.sd-g-lg-3,.sd-gx-lg-3{--sd-gutter-x: 1rem}.sd-g-lg-4,.sd-gy-lg-4{--sd-gutter-y: 1.5rem}.sd-g-lg-4,.sd-gx-lg-4{--sd-gutter-x: 1.5rem}.sd-g-lg-5,.sd-gy-lg-5{--sd-gutter-y: 3rem}.sd-g-lg-5,.sd-gx-lg-5{--sd-gutter-x: 3rem}}@media(min-width: 1200px){.sd-col-xl-auto{-ms-flex:0 0 auto;flex:0 0 auto;width:auto}.sd-col-xl-1{-ms-flex:0 0 auto;flex:0 0 auto;width:8.3333333333%}.sd-col-xl-2{-ms-flex:0 0 auto;flex:0 0 auto;width:16.6666666667%}.sd-col-xl-3{-ms-flex:0 0 auto;flex:0 0 auto;width:25%}.sd-col-xl-4{-ms-flex:0 0 auto;flex:0 0 auto;width:33.3333333333%}.sd-col-xl-5{-ms-flex:0 0 auto;flex:0 0 auto;width:41.6666666667%}.sd-col-xl-6{-ms-flex:0 0 auto;flex:0 0 auto;width:50%}.sd-col-xl-7{-ms-flex:0 0 auto;flex:0 0 auto;width:58.3333333333%}.sd-col-xl-8{-ms-flex:0 0 auto;flex:0 0 auto;width:66.6666666667%}.sd-col-xl-9{-ms-flex:0 0 auto;flex:0 0 auto;width:75%}.sd-col-xl-10{-ms-flex:0 0 auto;flex:0 0 auto;width:83.3333333333%}.sd-col-xl-11{-ms-flex:0 0 auto;flex:0 0 auto;width:91.6666666667%}.sd-col-xl-12{-ms-flex:0 0 auto;flex:0 0 auto;width:100%}.sd-g-xl-0,.sd-gy-xl-0{--sd-gutter-y: 0}.sd-g-xl-0,.sd-gx-xl-0{--sd-gutter-x: 0}.sd-g-xl-1,.sd-gy-xl-1{--sd-gutter-y: 0.25rem}.sd-g-xl-1,.sd-gx-xl-1{--sd-gutter-x: 0.25rem}.sd-g-xl-2,.sd-gy-xl-2{--sd-gutter-y: 0.5rem}.sd-g-xl-2,.sd-gx-xl-2{--sd-gutter-x: 0.5rem}.sd-g-xl-3,.sd-gy-xl-3{--sd-gutter-y: 1rem}.sd-g-xl-3,.sd-gx-xl-3{--sd-gutter-x: 1rem}.sd-g-xl-4,.sd-gy-xl-4{--sd-gutter-y: 1.5rem}.sd-g-xl-4,.sd-gx-xl-4{--sd-gutter-x: 1.5rem}.sd-g-xl-5,.sd-gy-xl-5{--sd-gutter-y: 3rem}.sd-g-xl-5,.sd-gx-xl-5{--sd-gutter-x: 3rem}}.sd-flex-row-reverse{flex-direction:row-reverse !important}details.sd-dropdown{position:relative;font-size:var(--sd-fontsize-dropdown)}details.sd-dropdown:hover{cursor:pointer}details.sd-dropdown .sd-summary-content{cursor:default}details.sd-dropdown summary.sd-summary-title{padding:.5em .6em .5em 1em;font-size:var(--sd-fontsize-dropdown-title);font-weight:var(--sd-fontweight-dropdown-title);user-select:none;-moz-user-select:none;-ms-user-select:none;-webkit-user-select:none;list-style:none;display:inline-flex;justify-content:space-between}details.sd-dropdown summary.sd-summary-title::-webkit-details-marker{display:none}details.sd-dropdown summary.sd-summary-title:focus{outline:none}details.sd-dropdown summary.sd-summary-title .sd-summary-icon{margin-right:.6em;display:inline-flex;align-items:center}details.sd-dropdown summary.sd-summary-title .sd-summary-icon svg{opacity:.8}details.sd-dropdown summary.sd-summary-title .sd-summary-text{flex-grow:1;line-height:1.5;padding-right:.5rem}details.sd-dropdown summary.sd-summary-title .sd-summary-state-marker{pointer-events:none;display:inline-flex;align-items:center}details.sd-dropdown summary.sd-summary-title .sd-summary-state-marker svg{opacity:.6}details.sd-dropdown summary.sd-summary-title:hover .sd-summary-state-marker svg{opacity:1;transform:scale(1.1)}details.sd-dropdown[open] summary .sd-octicon.no-title{visibility:hidden}details.sd-dropdown .sd-summary-chevron-right{transition:.25s}details.sd-dropdown[open]>.sd-summary-title .sd-summary-chevron-right{transform:rotate(90deg)}details.sd-dropdown[open]>.sd-summary-title .sd-summary-chevron-down{transform:rotate(180deg)}details.sd-dropdown:not([open]).sd-card{border:none}details.sd-dropdown:not([open])>.sd-card-header{border:1px solid var(--sd-color-card-border);border-radius:.25rem}details.sd-dropdown.sd-fade-in[open] summary~*{-moz-animation:sd-fade-in .5s ease-in-out;-webkit-animation:sd-fade-in .5s ease-in-out;animation:sd-fade-in .5s ease-in-out}details.sd-dropdown.sd-fade-in-slide-down[open] summary~*{-moz-animation:sd-fade-in .5s ease-in-out,sd-slide-down .5s ease-in-out;-webkit-animation:sd-fade-in .5s ease-in-out,sd-slide-down .5s ease-in-out;animation:sd-fade-in .5s ease-in-out,sd-slide-down .5s ease-in-out}.sd-col>.sd-dropdown{width:100%}.sd-summary-content>.sd-tab-set:first-child{margin-top:0}@keyframes sd-fade-in{0%{opacity:0}100%{opacity:1}}@keyframes sd-slide-down{0%{transform:translate(0, -10px)}100%{transform:translate(0, 0)}}.sd-tab-set{border-radius:.125rem;display:flex;flex-wrap:wrap;margin:1em 0;position:relative}.sd-tab-set>input{opacity:0;position:absolute}.sd-tab-set>input:checked+label{border-color:var(--sd-color-tabs-underline-active);color:var(--sd-color-tabs-label-active)}.sd-tab-set>input:checked+label+.sd-tab-content{display:block}.sd-tab-set>input:not(:checked)+label:hover{color:var(--sd-color-tabs-label-hover);border-color:var(--sd-color-tabs-underline-hover)}.sd-tab-set>input:focus+label{outline-style:auto}.sd-tab-set>input:not(.focus-visible)+label{outline:none;-webkit-tap-highlight-color:transparent}.sd-tab-set>label{border-bottom:.125rem solid transparent;margin-bottom:0;color:var(--sd-color-tabs-label-inactive);border-color:var(--sd-color-tabs-underline-inactive);cursor:pointer;font-size:var(--sd-fontsize-tabs-label);font-weight:700;padding:1em 1.25em .5em;transition:color 250ms;width:auto;z-index:1}html .sd-tab-set>label:hover{color:var(--sd-color-tabs-label-active)}.sd-col>.sd-tab-set{width:100%}.sd-tab-content{box-shadow:0 -0.0625rem var(--sd-color-tabs-overline),0 .0625rem var(--sd-color-tabs-underline);display:none;order:99;padding-bottom:.75rem;padding-top:.75rem;width:100%}.sd-tab-content>:first-child{margin-top:0 !important}.sd-tab-content>:last-child{margin-bottom:0 !important}.sd-tab-content>.sd-tab-set{margin:0}.sd-sphinx-override,.sd-sphinx-override *{-moz-box-sizing:border-box;-webkit-box-sizing:border-box;box-sizing:border-box}.sd-sphinx-override p{margin-top:0}:root{--sd-color-primary: #0071bc;--sd-color-secondary: #6c757d;--sd-color-success: #28a745;--sd-color-info: #17a2b8;--sd-color-warning: #f0b37e;--sd-color-danger: #dc3545;--sd-color-light: #f8f9fa;--sd-color-muted: #6c757d;--sd-color-dark: #212529;--sd-color-black: black;--sd-color-white: white;--sd-color-primary-highlight: #0060a0;--sd-color-secondary-highlight: #5c636a;--sd-color-success-highlight: #228e3b;--sd-color-info-highlight: #148a9c;--sd-color-warning-highlight: #cc986b;--sd-color-danger-highlight: #bb2d3b;--sd-color-light-highlight: #d3d4d5;--sd-color-muted-highlight: #5c636a;--sd-color-dark-highlight: #1c1f23;--sd-color-black-highlight: black;--sd-color-white-highlight: #d9d9d9;--sd-color-primary-bg: rgba(0, 113, 188, 0.2);--sd-color-secondary-bg: rgba(108, 117, 125, 0.2);--sd-color-success-bg: rgba(40, 167, 69, 0.2);--sd-color-info-bg: rgba(23, 162, 184, 0.2);--sd-color-warning-bg: rgba(240, 179, 126, 0.2);--sd-color-danger-bg: rgba(220, 53, 69, 0.2);--sd-color-light-bg: rgba(248, 249, 250, 0.2);--sd-color-muted-bg: rgba(108, 117, 125, 0.2);--sd-color-dark-bg: rgba(33, 37, 41, 0.2);--sd-color-black-bg: rgba(0, 0, 0, 0.2);--sd-color-white-bg: rgba(255, 255, 255, 0.2);--sd-color-primary-text: #fff;--sd-color-secondary-text: #fff;--sd-color-success-text: #fff;--sd-color-info-text: #fff;--sd-color-warning-text: #212529;--sd-color-danger-text: #fff;--sd-color-light-text: #212529;--sd-color-muted-text: #fff;--sd-color-dark-text: #fff;--sd-color-black-text: #fff;--sd-color-white-text: #212529;--sd-color-shadow: rgba(0, 0, 0, 0.15);--sd-color-card-border: rgba(0, 0, 0, 0.125);--sd-color-card-border-hover: hsla(231, 99%, 66%, 1);--sd-color-card-background: transparent;--sd-color-card-text: inherit;--sd-color-card-header: transparent;--sd-color-card-footer: transparent;--sd-color-tabs-label-active: hsla(231, 99%, 66%, 1);--sd-color-tabs-label-hover: hsla(231, 99%, 66%, 1);--sd-color-tabs-label-inactive: hsl(0, 0%, 66%);--sd-color-tabs-underline-active: hsla(231, 99%, 66%, 1);--sd-color-tabs-underline-hover: rgba(178, 206, 245, 0.62);--sd-color-tabs-underline-inactive: transparent;--sd-color-tabs-overline: rgb(222, 222, 222);--sd-color-tabs-underline: rgb(222, 222, 222);--sd-fontsize-tabs-label: 1rem;--sd-fontsize-dropdown: inherit;--sd-fontsize-dropdown-title: 1rem;--sd-fontweight-dropdown-title: 700}
_static/ 0000775 0001750 0001750 00000000000 14744715212 012707 5 ustar jfpiolle jfpiolle _static/styles/ 0000775 0001750 0001750 00000000000 14744715206 014235 5 ustar jfpiolle jfpiolle _static/styles/sphinx-book-theme.css.map 0000664 0001750 0001750 00000101713 14632365026 021064 0 ustar jfpiolle jfpiolle {"version":3,"file":"styles/sphinx-book-theme.css","mappings":"AAAA;;;;;;;EAAA,CC0CA,6CAGE,yBAA0B,CAG1B,6BAA8B,CAKhC,uBAEE,gCAAyC,CAEzC,2BAA4B,CAG9B,sBAEE,2BAA4B,CAG5B,gCAAyC,CAEzC,8BAA+B,CChEjC,KAIE,wBAOF,yBAGE,SAEA,MAAK,CAJL,kBAGA,MAFA,OAGA,CAYF,gBACE,aAEA,aAHF,WAII,wBAKJ,SAEI,uBAPA,CC9BF,6JAME,6BAIF,kDAEE,gBAKJ,kBACE,cACA,oBACA,eAGF,MACE,kBC1BF,aAEI,qBAEE,YADA,gBACA,CAEA,yCACE,cAEA,4CACE,cAEA,eAAc,CADd,iBACA,CAIJ,iCACE,cAGA,kDACE,aAKJ,gCACE,sBAIF,wBAEE,kBADA,cACA,CAEF,gGAIE,kBACA,WAGF,2BACE,mBAGF,yBACE,qBAGF,kCACE,aAIF,8GAGE,YAGF,6BACE,eAGF,mCACE,qBACA,cACA,gDACE,wBACA,+BACA,0BACA,kDACE,+BAEF,mDACE,4BAEF,qDACE,aAOR,4BACE,wBC3FN,wBACE,+CACA,WCFF,qBAEE,qBCFF,2CAME,WAAU,CAFV,iBAFA,SAIA,CAEA,yBARF,2CAUI,qDAGF,uDAEE,kBADA,kBACA,CACA,wBAHF,uDAKI,kBADA,kBACA,EAKF,8IACE,+CCNJ,wBADF,qCAEI,sBAEF,wBAJF,qCAKI,iBAMF,yBADF,uCAEI,cAEF,wBAJF,uCAKI,iBAKJ,mBAEE,mBAGA,6CAJA,aAMA,eACA,eALA,gBACA,MAEA,oBAQA,YPjCc,CO6Bd,wBAVF,mBA5BI,cAwCA,iBAOF,6BACE,kDAIF,0CACE,UAIF,yCAEE,mBADA,aAEA,WP1CoB,CO2CpB,WAIF,wCAEE,mBADA,YACA,CAOF,2CACE,aAIF,wBAUE,mBANA,YADA,kCAMA,aAPA,iBAGA,mBACA,mBAIA,CAGA,4BACE,aAIF,2DAGE,YADA,gCACA,CACA,yFACE,cAGJ,8BACE,gBAKA,8CACE,aAMN,gCAEE,mBADA,YACA,CAGF,wCAEE,SAGA,sIAGE,UAIF,uFAEE,+BAEF,6FAEE,iCACA,wMAEE,iCAMN,kCAaE,6CADA,qCCvJF,+FACE,CDwJA,kCAPA,SACA,0BAMA,CAZA,wCACE,cAaF,iDAEE,mBADA,oBAYA,cAVA,iBAUA,CAPA,uDAEE,yBACA,iCAFA,oBAEA,CAOF,0DACE,WAGF,0EAEE,mBACA,oBACA,uBAHA,WAGA,CEvMR,WAEE,iBAIA,iCACE,aCHJ,oBAGE,iBAGA,aAJA,MAOA,gFACE,CAIF,wBAdF,oBAgBI,cAIF,kDACE,gBAIF,wBAzBF,oBA0BI,cVF+B,CUUjC,6EAGE,iBAEA,SAAQ,CADR,iBACA,CVf+B,CWxBnC,sBAEE,MAEA,yBAJF,sBAMI,cAIF,+CAEE,aACA,UAFA,SAEA,CAGA,uEAEE,gBAAe,CADf,aACA,CAKJ,kCAKE,mBAEA,6BAJA,aACA,UAHA,WXDoB,CWMpB,SAJA,eAKA,CAIF,yBAlCF,sBAmCI,uCACA,mBAOA,SAAQ,CANR,+BAGA,SAGA,CAGA,gCAEE,2CAEA,cAGA,6CAEE,gBAGA,4BAMJ,uCAEE,eX3CkB,CW4ClB,kBAGA,iDACE,yCAIF,yDAEE,YACA,iCACA,gBAHA,UAIA,kBACA,4BAIF,oDACE,WCvFR,OACE,uCACA,yBAIE,0BAHA,aACA,eAGA,gBAFA,YZ6BoB,CY1BpB,mDACE,eACA,qDACE,gBCdR,mBACE,eACA,wBAFF,mBAII,iBCJJ,iBASE,gBALA,yBAJF,iBAKI,wBCDF,uCACE,iBAIE,yGAEE,iBAIF,qDACE,gBChBR,cAKE,sBAEA,WANA,aAKA,uBAJA,gBAKA,CAGA,oBACE,qBAEF,2BACE,kBAEA,kBADA,kBACA,CAGF,2BACE,aCnBJ,qBACE,WAGE,oDACE,aAMN,qBAIE,aAFA,gBADA,UAGA,CAEA,kDACE,iBAKJ,wBACE,eACE,uBAGF,qBACE,cAMJ,cAEE,kBADA,kBACA,CACA,wBAHF,cAKI,kBADA,kBACA,EAKA,wBAFF,+BAGI,cACA,iCACE,gBChDR,IACE,eAEA,iBAGE,cAFA,iBACA,iBACA,CAGF,eACE,WACA,WACA,iBAGF,gBACE,YACA,YACA,gBAKJ,WAEE,kBACA,kBAFA,UAEA,CAEA,sBACE,gBACA,gCACE,cAGJ,uBACE,iBACA,iCACE,eAIJ,qBACE,gBAKA,gEACE,cAIJ,oCACE,gBAGF,+BACE,gBAGF,gBACE,gBCHJ,oBACE,gBACA,qCACE,aAEF,wBACE,iBAEF,wBARF,oBAUI,cADA,cACA,CACA,qCACE,eACA,2CACE,aAMR,oBACE,aACA,wBACE,8EAKE,WAHA,cACA,WACA,UAGA,iBACA,kBAFA,SAEA,EAKN,8BAlEE,uBA0EA,iBA3EA,YAEA,eACA,kBAmEA,kBAvEA,UAsEA,SAMA,CAJA,sCACE,iBAlEF,8BA6DF,8BAxDI,YAHA,kBADA,SAIA,CAEA,8DAEE,mBADA,oBAEA,eAGA,kEACE,eACA,iBAuDN,wBATF,8BAUI,cAKF,oBAEE,YACA,iBAGF,gCACE,mBAWF,0CACE,aAMF,iCACE,aACA,eACA,gBAGA,mDACE,cACA,eAIJ,wBAtBF,qBAwBI,YAGA,iCACE,cACA,kBAKN,mGAlIE,uBADA,YAEA,eACA,kBAuIA,kBA3IA,UA0IA,SAtIA,CAGA,8BA6HF,mGAxHI,YAHA,kBADA,SAIA,CAEA,mMAEE,mBADA,oBAEA,eAGA,+MACE,eACA,iBAyHN,ySACE,eAKJ,0GAnJE,uBADA,YAEA,eACA,kBAqJA,kBAzJA,UAwJA,SApJA,CAGA,8BA8IF,0GAzII,YAHA,kBADA,SAIA,CAEA,0JAEE,mBADA,oBAEA,eAGA,gKACE,eACA,iBAwIR,2BACE,gBAUF,8EAKE,kBADA,SACA,CACA,wBANF,8EAOI,cATsB,CAUtB,UAVsB,EC7LxB,gEAKE,6CADA,iBADA,gBAEA,CAGF,+BAIE,cAFA,eADA,kBAIA,kBAFA,gBAEA,CCjBJ,2BAEE,WCIF,+HACE,gBACA,gBCFF,kBACE,kCAEE,cCNJ,eACE,sBACA,4BAGF,+BACE,4BAGF,yBACE,0BAGF,2BAEE,cADA,YACA","sources":["webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/index.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/abstracts/_variables.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/base/_base.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/base/_typography.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/base/_print.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/sections/_announcement.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/sections/_article.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/sections/_article-container.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/sections/_header-article.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/abstracts/_mixins.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/sections/_header-primary.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/sections/_sidebar-primary.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/sections/_sidebar-secondary.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/sections/_footer-content.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/sections/_footer-article.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/components/_back-to-top.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/components/_icon-links.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/components/_logo.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/components/_search.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/content/_images.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/content/_margin.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/content/_quotes.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/content/_code.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/content/_notebooks.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/extensions/_comments.scss","webpack://sphinx_book_theme/./src/sphinx_book_theme/assets/styles/extensions/_thebe.scss"],"sourcesContent":["/*! sphinx-book-theme CSS\n * BSD 3-Clause License\n * Copyright (c) 2020, EBP\n * All rights reserved.\n *\n * This follows the 7-1 pattern described here:\n * https://sass-guidelin.es/#architecture\n */\n// Variables and re-usable SCSS functions\n@import \"abstracts/mixins\";\n@import \"abstracts/variables\";\n\n// Basic styling applied throughout site\n@import \"base/base\";\n@import \"base/typography\";\n@import \"base/print\";\n\n// Major theme layout, skeleton, and whitespace\n@import \"sections/announcement\";\n@import \"sections/article\";\n@import \"sections/article-container\";\n@import \"sections/header-article\";\n@import \"sections/header-primary\";\n@import \"sections/sidebar-primary\";\n@import \"sections/sidebar-secondary\";\n@import \"sections/footer-content\";\n@import \"sections/footer-article\";\n\n// Re-usable components across the theme\n@import \"components/back-to-top\";\n@import \"components/icon-links\";\n@import \"components/logo\";\n@import \"components/search\";\n\n// Content blocks in standard Sphinx\n@import \"content/images\";\n@import \"content/margin\";\n@import \"content/quotes\";\n@import \"content/code\";\n@import \"content/notebooks\";\n\n// Content blocks from Sphinx extensions\n\n@import \"extensions/comments\";\n@import \"extensions/thebe\";\n","/*********************************************\n* Variables *\n*********************************************/\n// Breakpoints from Bootstrap: https://getbootstrap.com/docs/5.0/layout/breakpoints/\n$breakpoint-xxl: 1200px;\n$breakpoint-xl: 1200px;\n$breakpoint-lg: 992px;\n$breakpoint-md: 768px;\n$breakpoint-sm: 576px;\n\n// A few semantic z-indices\n$zindex-bottom: 1;\n$zindex-middle: 2;\n$zindex-top: 3;\n\n// Semantic Z-index from bootstrap. Copied here so we can re-use if needed.\n// ref: https://getbootstrap.com/docs/5.0/layout/z-index/\n$zindex-dropdown: 1000;\n$zindex-sticky: 1020;\n$zindex-fixed: 1030;\n$zindex-modal-backdrop: 1040;\n$zindex-offcanvas: 1050;\n$zindex-modal: 1060;\n$zindex-popover: 1070;\n$zindex-tooltip: 1080;\n\n// Spacing\n$header-article-height: 3rem;\n$sidebar-primary-width-widescreen: 20%;\n$toc-width-mobile: 75%;\n\n// Consistent styling for page elements\n$box-border-radius: 0.4em;\n\n$animation-time: 0.25s;\n\n// Font sizes\n$sbt-font-size-small-1: 87.5%;\n\n/**\n * Variables that aren't impacted by light/dark\n */\nhtml[data-theme=\"light\"],\nhtml[data-theme=\"dark\"] {\n // Over-ride the pydata theme so that readers can use their system base\n --pst-font-size-base: none;\n // Default secondary color (has enough contrast on both light/dark so\n // no need to special case.\n --pst-color-secondary: #e89217;\n}\n\n// Overrides for pydata sphinx theme.\n// See https://github.com/pydata/pydata-sphinx-theme/blob/master/pydata_sphinx_theme/static/css/theme.css\nhtml[data-theme=\"light\"] {\n // Announcement\n --sbt-color-announcement: rgb(97, 97, 97);\n // Default primary color (need to adjust on dark theme due to bad contrast)\n --pst-color-primary: #176de8;\n}\n\nhtml[data-theme=\"dark\"] {\n // Slightly lighten these colors to make them stand out more on dark\n --pst-color-primary: #528fe4;\n\n // Over-ride the purple announcement color\n --sbt-color-announcement: rgb(97, 97, 97);\n // Desaturate the background\n --pst-color-background: #121212;\n}\n","/**\n * General structural things\n */\nhtml {\n // The PyData theme value for this is based on `header-height` variable.\n // We set the variable to 0 and have our own $article-header-height SCSS variable.\n // So here we follow the same pattern but now using our variable.\n scroll-padding-top: $header-article-height + 1rem;\n}\n\n/**\n* Utility classes used in a few places\n*/\n// For the helper pixel that we can watch to decide whether we've scrolled\n.sbt-scroll-pixel-helper {\n position: absolute;\n width: 0px;\n height: 0px;\n top: 0;\n left: 0;\n}\n\n// We define our own display-none class since bootstrap uses !important and we want to be able to over-ride\n.d-n {\n display: none;\n}\n\n/**\n * Printing behavior\n */\n// Only display upon printing\n.onlyprint {\n display: none;\n\n @media print {\n display: block !important;\n }\n}\n\n// Prevent an item from being printed\n.noprint {\n @media print {\n display: none !important;\n }\n}\n","/*********************************************\n* Basic text formatting and content structure *\n*********************************************/\n\n.bd-article-container {\n h1,\n h2,\n h3,\n h4,\n h5,\n p.caption {\n color: var(--pst-color-muted);\n }\n\n // Top two headers are slightly bolder\n h1,\n h2 {\n font-weight: 500;\n }\n}\n\n// counteracting pydata style on a::before, for citation style\na.brackets::before {\n color: inherit;\n font-family: inherit;\n margin-right: 0rem;\n}\n\ntable {\n position: relative;\n}\n","/*********************************************\n* Print-specific CSS *\n*********************************************/\n@media print {\n .bd-main {\n .bd-content {\n margin-left: 2rem;\n height: auto;\n // Structural elements\n #jb-print-docs-body {\n margin-left: 0rem;\n\n h1 {\n font-size: 3em;\n text-align: center;\n margin-bottom: 0;\n }\n }\n // Main content adjustments\n .bd-article {\n padding-top: 0;\n\n // The first H1 is the title, we've already displayed above\n h1:first-of-type {\n display: none;\n }\n }\n\n // HACK: Without this, some code cells take the whole width\n .container {\n min-width: 0% !important;\n }\n\n // Content\n h1 {\n margin-top: 1em;\n margin-bottom: 1em;\n }\n h1,\n h2,\n h3,\n h4 {\n break-after: avoid;\n color: black;\n }\n\n table {\n break-inside: avoid;\n }\n\n pre {\n word-wrap: break-word;\n }\n\n a.headerlink {\n display: none;\n }\n\n // Remove borders to save some ink\n blockquote.epigraph,\n aside.margin,\n aside.sidebar {\n border: none;\n }\n\n .footer {\n margin-top: 1em;\n }\n // Print-only table of contents\n #jb-print-toc {\n margin-bottom: 1.5rem;\n margin-left: 0rem;\n .section-nav {\n border-left: 0px !important;\n list-style-type: disc !important;\n margin-left: 3em !important;\n a {\n text-decoration: none !important;\n }\n li {\n display: list-item !important;\n }\n .nav {\n display: none;\n }\n }\n }\n }\n\n // Hide the footer on printing\n .bd-footer-content {\n display: none !important;\n }\n }\n}\n",".bd-header-announcement {\n background-color: var(--sbt-color-announcement);\n color: #fff;\n}\n",".bd-main .bd-content {\n // make article container left aligned in absence of sidebar\n justify-content: left;\n}\n",".bd-main .bd-content .bd-article-container {\n // Re-adjust padding defaults to be flush on the top and right\n padding: 0rem;\n // Unset overflow x so that sticky: top works for the article header\n overflow-x: unset;\n // prevent from overflowing the flex container\n min-width: 0;\n\n @media (min-width: $breakpoint-xl) {\n // keep article at reasonable width in absence of sidebar\n max-width: calc(100% - var(--pst-sidebar-secondary));\n }\n\n .bd-article {\n padding-right: 2rem;\n padding-left: 2rem;\n @media (max-width: $breakpoint-md) {\n padding-right: 1rem;\n padding-left: 1rem;\n }\n }\n details.above-input,\n details.below-input {\n summary {\n border-left: 3px solid var(--pst-color-primary);\n }\n }\n}\n","/*********************************************\n* Top Bar *\n*********************************************/\n/**\n * Mixin:\n * Header behavior on mobile\n */\n@mixin header-height-mobile {\n @media (max-width: $breakpoint-md) {\n height: $header-article-height + 0.5rem;\n }\n}\n\n/**\n * Sidebar toggle over-rides for PST\n */\n// Primary toggle is always visible\nbutton.sidebar-toggle.primary-toggle {\n @media (min-width: $breakpoint-md) {\n display: inline-block;\n }\n @media (max-width: $breakpoint-md) {\n margin-bottom: 0px;\n }\n}\n\n// Secondary toggle mimics behavior of \"persistent header\" div of PST\nbutton.sidebar-toggle.secondary-toggle {\n @media (min-width: $breakpoint-xl) {\n display: none;\n }\n @media (max-width: $breakpoint-md) {\n margin-bottom: 0px;\n }\n}\n\n// Wrapper container\n.bd-header-article {\n display: flex;\n align-items: center;\n position: sticky;\n top: 0;\n background-color: var(--pst-color-background);\n transition: left 0.2s;\n font-size: 0.9em;\n padding: 0 1rem;\n\n @media (max-width: $breakpoint-md) {\n // Give mobile view a bit more space for text\n padding: 0 0.5rem;\n }\n z-index: $zindex-sticky;\n\n @include header-height-mobile;\n\n // The box shadow that shows up when you've scrolled past the top\n .scrolled & {\n box-shadow: 0 6px 6px -6px var(--pst-color-shadow);\n }\n\n // Remove inner padding so that spacing of buttons is a bit tighter\n .header-article__inner {\n padding: 0;\n }\n\n // Inner container with items in it\n .header-article-items {\n display: flex;\n align-items: center;\n height: $header-article-height;\n width: 100%;\n }\n\n // Contains the individual item components so we want it centered\n .header-article-item {\n display: flex;\n align-items: center;\n }\n\n /**\n * Buttons in the header\n */\n // A series of buttons we special-case in the theme\n .article-header-buttons {\n display: flex;\n }\n\n // Generic button styles\n .btn {\n // Basic button size\n font-size: 1.3rem;\n color: var(--pst-color-text-muted);\n border: none;\n padding-left: 0.5rem;\n padding-right: 0.5rem;\n\n // Make sure anything inside is aligned vertically\n display: flex;\n align-items: center;\n\n // Fix width of buttons so they're all the same\n svg {\n width: 1.3rem;\n }\n\n // Hover / active behavior\n &.show,\n &:hover {\n color: var(--pst-color-text-base);\n border: none;\n & + .dropdown-menu {\n display: block;\n }\n }\n &:focus {\n box-shadow: none;\n }\n\n &.dropdown-toggle {\n // Hide the bootstrap caret\n &:after {\n display: none;\n }\n }\n }\n\n // Vertically align dropdown buttons\n div.dropdown {\n display: flex;\n align-items: center;\n }\n\n .theme-switch-button {\n // Removing some special-casing that was needed in PST\n margin: 0;\n\n // Remove extra padding since it is already there between sidebar items\n span,\n i,\n button {\n padding: 0;\n }\n\n // No background on hover. Need important to over-ride the PST which uses it too.\n span,\n i {\n transition: color $animation-time ease-out;\n }\n &:active,\n &:hover {\n background-color: unset !important;\n span,\n i {\n color: var(--pst-color-text-base);\n }\n }\n }\n\n // The menu that is normally hidden until you hover\n .dropdown-menu {\n // Hidden unless we are hovering\n &:hover {\n display: block;\n }\n\n // Positioning and layout of dropdown items to be standardized\n top: 2rem;\n transform: translateX(-75%);\n @include pst-box-shadow;\n\n // Color and shadowing\n border-color: var(--pst-color-border);\n background-color: var(--pst-color-background);\n color: var(--pst-color-text-muted);\n\n .dropdown-item {\n display: inline-flex;\n align-items: center;\n padding-left: 0.5em;\n\n // To prevent link underline from showing up\n &:hover {\n text-decoration: none;\n background-color: initial;\n color: var(--pst-color-text-base);\n }\n\n // Slightly smaller font for everything\n font-size: 1em;\n\n // Image icons should be the same height as icons\n span img {\n height: 1em;\n }\n\n span.btn__icon-container {\n width: 1.7em;\n align-items: center;\n display: inline-flex;\n justify-content: center;\n }\n }\n }\n}\n","/*********************************************\n* SASS Mixins\n*********************************************/\n/**\n* Hide the scrollbar until the element is hovered, so keep the page clean\n* Use this sparingly because it's not a great UX pattern.\n*/\n@mixin scrollbar-on-hover() {\n &:not(:hover) {\n &::-webkit-scrollbar-thumb {\n visibility: hidden;\n }\n }\n}\n\n/**\n * The PyData Sphinx Theme box shadow rule\n * Copied here in csae we need to re-use.\n*/\n@mixin pst-box-shadow() {\n box-shadow:\n 0 0.2rem 0.5rem var(--pst-color-shadow),\n 0 0 0.0625rem var(--pst-color-shadow) !important;\n}\n",".bd-header {\n // Turn off sticky positioning so that it scrolls\n position: inherit;\n\n // Turn these off because we'll show it in the article header\n // The primary sidebar toggle\n button.sidebar-toggle {\n display: none;\n }\n}\n","/*********************************************\n* Left Nav Bar *\n*********************************************/\n\n.bd-sidebar-primary {\n // So that it sticks to the top of the page instead of the header height\n top: 0;\n max-height: 100vh;\n\n // Tighter padding so the spacing is more equal\n padding: 1rem;\n\n // Draw open/close animation\n transition:\n margin-left $animation-time ease 0s,\n opacity $animation-time ease 0s,\n visibility $animation-time ease 0s;\n\n @media (max-width: $breakpoint-md) {\n // So that tooltips don't overlap\n z-index: $zindex-tooltip + 1;\n }\n\n // Remove the top border since there's often no header items above\n .sidebar-primary-items__start {\n border-top: none;\n }\n\n // On wide screens we have a smaller sidebar width than PST\n @media (min-width: $breakpoint-lg) {\n flex-basis: $sidebar-primary-width-widescreen;\n }\n}\n\n// Default visibility for left sidebar is the reverse of what it is on mobile.\n// It is shown by default, and hidden with a click.\n// Mobile behavior is defined in the pydata sphinx theme\n@media (min-width: $breakpoint-lg) {\n input#pst-primary-sidebar-checkbox:checked\n ~ .bd-container\n .bd-sidebar-primary {\n margin-left: -$sidebar-primary-width-widescreen;\n visibility: hidden;\n opacity: 0;\n }\n}\n","/*********************************************\n* Table of Contents (right nav bar) *\n*********************************************/\n\n.bd-sidebar-secondary {\n // So that it sticks to the top of the page instead of the header height\n top: 0;\n\n @media (max-width: $breakpoint-xl) {\n // So that tooltips don't overlap\n z-index: $zindex-tooltip + 1;\n }\n\n // So that we can center the TOC button with the article header buttons\n .sidebar-secondary-items {\n padding: 0;\n display: flex;\n gap: 0.5rem;\n\n // Remove the manual padding since we'll use `gap`\n .sidebar-secondary-item {\n padding-top: 0;\n padding-bottom: 0;\n }\n }\n\n // The 'on this page' title div should take up the full header\n .onthispage {\n height: $header-article-height;\n min-height: $header-article-height;\n display: flex;\n gap: 0.5rem;\n align-items: center;\n margin: 0;\n color: var(--pst-color-muted);\n }\n\n // Wide screen behavior\n @media (min-width: $breakpoint-xl) {\n background: var(--pst-color-background);\n height: fit-content;\n transition: max-height 0.4s ease;\n\n // To make sure it shows above the page content\n z-index: $zindex-middle;\n\n // Remove padding so that it's flush on the top and left\n padding: 0;\n\n // This is the container div for the secondary sidebar nav\n .toc-item {\n // Border is a bit less prominent\n border-left-color: var(--pst-color-surface);\n // Flush with the top so that we can fix the height of the toc header div\n padding-top: 0;\n\n // The table of contents
` all receive top and bottom margins. We nuke the top\n// margin for easier control within type scales as it avoids margin collapsing.\n\n%heading {\n margin-top: 0; // 1\n margin-bottom: $headings-margin-bottom;\n font-family: $headings-font-family;\n font-style: $headings-font-style;\n font-weight: $headings-font-weight;\n line-height: $headings-line-height;\n color: var(--#{$prefix}heading-color);\n}\n\nh1 {\n @extend %heading;\n @include font-size($h1-font-size);\n}\n\nh2 {\n @extend %heading;\n @include font-size($h2-font-size);\n}\n\nh3 {\n @extend %heading;\n @include font-size($h3-font-size);\n}\n\nh4 {\n @extend %heading;\n @include font-size($h4-font-size);\n}\n\nh5 {\n @extend %heading;\n @include font-size($h5-font-size);\n}\n\nh6 {\n @extend %heading;\n @include font-size($h6-font-size);\n}\n\n\n// Reset margins on paragraphs\n//\n// Similarly, the top margin on `
`s get reset. However, we also reset the\n// bottom margin to use `rem` units instead of `em`.\n\np {\n margin-top: 0;\n margin-bottom: $paragraph-margin-bottom;\n}\n\n\n// Abbreviations\n//\n// 1. Add the correct text decoration in Chrome, Edge, Opera, and Safari.\n// 2. Add explicit cursor to indicate changed behavior.\n// 3. Prevent the text-decoration to be skipped.\n\nabbr[title] {\n text-decoration: underline dotted; // 1\n cursor: help; // 2\n text-decoration-skip-ink: none; // 3\n}\n\n\n// Address\n\naddress {\n margin-bottom: 1rem;\n font-style: normal;\n line-height: inherit;\n}\n\n\n// Lists\n\nol,\nul {\n padding-left: 2rem;\n}\n\nol,\nul,\ndl {\n margin-top: 0;\n margin-bottom: 1rem;\n}\n\nol ol,\nul ul,\nol ul,\nul ol {\n margin-bottom: 0;\n}\n\ndt {\n font-weight: $dt-font-weight;\n}\n\n// 1. Undo browser default\n\ndd {\n margin-bottom: .5rem;\n margin-left: 0; // 1\n}\n\n\n// Blockquote\n\nblockquote {\n margin: 0 0 1rem;\n}\n\n\n// Strong\n//\n// Add the correct font weight in Chrome, Edge, and Safari\n\nb,\nstrong {\n font-weight: $font-weight-bolder;\n}\n\n\n// Small\n//\n// Add the correct font size in all browsers\n\nsmall {\n @include font-size($small-font-size);\n}\n\n\n// Mark\n\nmark {\n padding: $mark-padding;\n color: var(--#{$prefix}highlight-color);\n background-color: var(--#{$prefix}highlight-bg);\n}\n\n\n// Sub and Sup\n//\n// Prevent `sub` and `sup` elements from affecting the line height in\n// all browsers.\n\nsub,\nsup {\n position: relative;\n @include font-size($sub-sup-font-size);\n line-height: 0;\n vertical-align: baseline;\n}\n\nsub { bottom: -.25em; }\nsup { top: -.5em; }\n\n\n// Links\n\na {\n color: rgba(var(--#{$prefix}link-color-rgb), var(--#{$prefix}link-opacity, 1));\n text-decoration: $link-decoration;\n\n &:hover {\n --#{$prefix}link-color-rgb: var(--#{$prefix}link-hover-color-rgb);\n text-decoration: $link-hover-decoration;\n }\n}\n\n// And undo these styles for placeholder links/named anchors (without href).\n// It would be more straightforward to just use a[href] in previous block, but that\n// causes specificity issues in many other styles that are too complex to fix.\n// See https://github.com/twbs/bootstrap/issues/19402\n\na:not([href]):not([class]) {\n &,\n &:hover {\n color: inherit;\n text-decoration: none;\n }\n}\n\n\n// Code\n\npre,\ncode,\nkbd,\nsamp {\n font-family: $font-family-code;\n @include font-size(1em); // Correct the odd `em` font sizing in all browsers.\n}\n\n// 1. Remove browser default top margin\n// 2. Reset browser default of `1em` to use `rem`s\n// 3. Don't allow content to break outside\n\npre {\n display: block;\n margin-top: 0; // 1\n margin-bottom: 1rem; // 2\n overflow: auto; // 3\n @include font-size($code-font-size);\n color: $pre-color;\n\n // Account for some code outputs that place code tags in pre tags\n code {\n @include font-size(inherit);\n color: inherit;\n word-break: normal;\n }\n}\n\ncode {\n @include font-size($code-font-size);\n color: var(--#{$prefix}code-color);\n word-wrap: break-word;\n\n // Streamline the style when inside anchors to avoid broken underline and more\n a > & {\n color: inherit;\n }\n}\n\nkbd {\n padding: $kbd-padding-y $kbd-padding-x;\n @include font-size($kbd-font-size);\n color: $kbd-color;\n background-color: $kbd-bg;\n @include border-radius($border-radius-sm);\n\n kbd {\n padding: 0;\n @include font-size(1em);\n font-weight: $nested-kbd-font-weight;\n }\n}\n\n\n// Figures\n//\n// Apply a consistent margin strategy (matches our type styles).\n\nfigure {\n margin: 0 0 1rem;\n}\n\n\n// Images and content\n\nimg,\nsvg {\n vertical-align: middle;\n}\n\n\n// Tables\n//\n// Prevent double borders\n\ntable {\n caption-side: bottom;\n border-collapse: collapse;\n}\n\ncaption {\n padding-top: $table-cell-padding-y;\n padding-bottom: $table-cell-padding-y;\n color: $table-caption-color;\n text-align: left;\n}\n\n// 1. Removes font-weight bold by inheriting\n// 2. Matches default `
` alignment by inheriting `text-align`.\n// 3. Fix alignment for Safari\n\nth {\n font-weight: $table-th-font-weight; // 1\n text-align: inherit; // 2\n text-align: -webkit-match-parent; // 3\n}\n\nthead,\ntbody,\ntfoot,\ntr,\ntd,\nth {\n border-color: inherit;\n border-style: solid;\n border-width: 0;\n}\n\n\n// Forms\n//\n// 1. Allow labels to use `margin` for spacing.\n\nlabel {\n display: inline-block; // 1\n}\n\n// Remove the default `border-radius` that macOS Chrome adds.\n// See https://github.com/twbs/bootstrap/issues/24093\n\nbutton {\n // stylelint-disable-next-line property-disallowed-list\n border-radius: 0;\n}\n\n// Explicitly remove focus outline in Chromium when it shouldn't be\n// visible (e.g. as result of mouse click or touch tap). It already\n// should be doing this automatically, but seems to currently be\n// confused and applies its very visible two-tone outline anyway.\n\nbutton:focus:not(:focus-visible) {\n outline: 0;\n}\n\n// 1. Remove the margin in Firefox and Safari\n\ninput,\nbutton,\nselect,\noptgroup,\ntextarea {\n margin: 0; // 1\n font-family: inherit;\n @include font-size(inherit);\n line-height: inherit;\n}\n\n// Remove the inheritance of text transform in Firefox\nbutton,\nselect {\n text-transform: none;\n}\n// Set the cursor for non-`
Comments:
Comments This is a land/sea/ice mask with the following bit values:
Bit 0:1 = water in grid
Bit 1:1 = land in grid
Bit 2:1 = optional, lake surface in grid
Bit 3:1 = sea ice
Bit 4:1 = optional, river surface in grid
Bits [5-7] spare
Note that the lake and river surface bit values are optional.
The
sourceattribute should list any data product used in creating this mask, a semi-colon separated list of identifiers <provider>_<type_of_mask>_<version_mask>.